Alban Browaeys <[EMAIL PROTECTED]> writes:
> Is it ok that double operators give diferents results with athlon TB
> than with other processors ?
No. But of course gcc can do nothing about it if it is the case;
complain to the hardware vendor.
> extract from the real mozilla code (cf bug #203100)
Jason Kraftcheck <[EMAIL PROTECTED]> writes:
> If the following is compiled with the options -Wall -pedantic-errors :
> #include
> int main( )
> {
> int i;
> printf("%p\n", &i );
> return 0;
> }
>
> gcc emits the following:
> voidptr.c: In function `main':
> voidptr.c:5:
Jason Kraftcheck <[EMAIL PROTECTED]> writes:
> The C standard says there's a difference between printing a void*
> and a int* (or any other type)? How can a pointer passed through a
> var-args list be anything but a void*? The C standard may say that
> %p prints a void*, but isn't any pointer pa
Jason Kraftcheck <[EMAIL PROTECTED]> writes:
> In practice, how can it be anything other than a void*?
It can't. You know, the "-pedantic" option is called "-pedantic" for a
reason. It doesn't make a difference on any existing gcc platform, but
it would be possible to cnstruct a C99-compliant env
"Magossa'nyi A'rpa" <[EMAIL PROTECTED]> writes:
> When compiling libzorpll on alpha, I got the following
> warning.
>
> In file included from /usr/include/resolv.h:62,
> from main.c:49:
> /usr/include/stdio.h:70: warning: redefinition of `va_list'
> /usr/lib/gcc-lib/alpha-linux/2
Andrew Suffield <[EMAIL PROTECTED]> writes:
> Package: gcc-3.3
>
> [This is also present in gcc-3.2, and probably all 3.x versions; it is
> inapplicable for 2.95, which didn't support dynamic arrays]
Huh? It did.
> int main(void)
> {
> int foo = 0;
> int bar;
> int len = 5;
> switch(foo
It looks like the code that is generated is actually correct, so it's
only a bogus warning. I suggest we forward it upstream.
I will create a separate gcc PR for the related problem discussed with
Andrew in private mail: gcc doesn't reject jumps into a VLA's scope.
--
Falk
<[EMAIL PROTECTED]> writes:
> gcc -march=i386 -fomit-frame-pointer -O2
>
> miscompiles sound/core/oss/rate.c in Linux 2.6.0-test9.
>
> I've attached the preprocessed source that demonstrates the
> problem.
The attachment seems corrupted, can you please resend it or put it
somewhere?
--
(damn, this mailer sucks, sorry for any mangling)
Bryce Wilcox-O'Hearn <[EMAIL PROTECTED]>:
> I use Crypto++ v5.0 [1], and I've noticed that the "generate a random
> RSA key pair" function either seg faults or goes into an infinite
> loop. I've learned that turning optimization off with -O0 or el
On Wed, 19 Nov 2003, Andreas Beckmann wrote:
> The offending line is
> .section".note.GNU-stack"
> at the end of the initialization of unsigned int check_asm_data[].
This is not valid sytax. It ought to be
.section = ".note.GNU-stack"
Please reassign to the source package.
Adam C Powell IV <[EMAIL PROTECTED]> writes:
> gcj-3.3 ICEs during at attempted build of babel 0.8.8. The compile
> command is quite ugly:
>
> javac -g -d . -classpath
> ../lib/java-getopt-1.0.7.jar:../lib/xerces-2.4.0.jar:../lib/jcert-1.0.1.jar:../lib/jnet-1.0.1.jar:../lib/external/jsse-1.0.1.j
Tyson Whitehead <[EMAIL PROTECTED]> writes:
> > This is an automatic notification regarding your Bug report
> > #212912: gcc-3.3: [alpha] Linux linker/loader does not support
> > -mieee-conformant, which was filed against the gcc-3.3 package.
> >
> > It has been closed by one of the developers, na
Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <[EMAIL PROTECTED]> writes:
> This patch has been recently announced in bugtraq and might be also
> relevant.
>
> Aside from providing these patches at debian/patches, is there any
> way they could be applied to the stock gcc-3.3 package?
Sin
Daniel Schepler <[EMAIL PROTECTED]> writes:
> icmp_echo_id.h: In destructor `virtual
>ICMP_Echo_Code_Chk::~ICMP_Echo_Code_Chk()':
> icmp_echo_id.h:58: internal compiler error: Segmentation fault
Confirmed. Working on extracting a test case.
--
Falk
Andre Woebbeking <[EMAIL PROTECTED]> writes:
> test.cpp:11: error: conflicting types for `None'
> test.cpp:4: error: previous declaration as `Enum1 None'
I cannot reproduce this with g++-3.3 (GCC) 3.3.2 (Debian), so it must
have been introduced recently.
--
Falk
Britton Leo Kerin <[EMAIL PROTECTED]> writes:
> static char *const foo = "baz";
> static int foo_len = strlen(foo);
> /* static int foo_len = an_impure_function(); */
> greenwood$ gcc test_const.c
> test_const.c: In function `main':
> test_const.c:14: error: initializer element is not const
Britton <[EMAIL PROTECTED]> writes:
> > > Replaceing the strlen call with a call of an impure function
> > > (commented out above) results in the above error whether or not -O is
> > > used. It seems to me that pure function should either always be
> > > usable in this way regardless of -O (and C
Martin Habets <[EMAIL PROTECTED]>, [EMAIL PROTECTED] schrieb am 14.01.05
18:24:52:
> I've been retesting this problem using the packages below,
> and the problem is still there. The assembler code generated
> looks exactly the same as before.
Please provide the preprocessed source as obtained wh
Daniel Silva <[EMAIL PROTECTED]> writes:
> configure:3100: gcc -c -march=pentium3 -O2 -foptimize-sibling-calls
> -finline-functions -fmerge-constants -fmerge-all-constants
> -funroll-loops -fnew-ra -fprefetch-loop-arrays -ffast-math
> -fno-math-errno -funsafe-math-optimizations -ffinite-math-only
Greg Kochanski <[EMAIL PROTECTED]> writes:
> Here's the code:
>
> box c_area(C xform_split &xf, C box& databox0, C box& databox1)
> {
> // Next is line 84:
> C box box0inOUTin(parallelogram(inverse(xf.back), databox0).insidebox());
> C box lc(inverse_image(databox1, xf.fwd));
> return intersec
Greg Kochanski <[EMAIL PROTECTED]> writes:
> You may assume that box, xform_split, and parallelogram are classes,
> that insidebox() is a member function of class parallelogram, and
> that inverse_image() and intersect() are functions.
I'm not willing to guess the test case, since my experience h
Greg Kochanski <[EMAIL PROTECTED]> writes:
> Why is the test case important?
Because I cannot reproduce the problem without it.
> I think (though I may be wrong) that you're missing the main point
> of the bug report.
>
> The main point is simply that the error message is uninformative.
> Nearly
tags 292961 + upstream
tags 292961 + fixed-upstream
retitle 292961 [fixed in 3.4] g++-3.3: vastly uninformative error message
thanks
Greg Kochanski <[EMAIL PROTECTED]> writes:
> OK. Here is a condensed version.
>
> $ g++ -c bug.c
> bug.c: In function `void c_area(const xform_split&, const box&, c
tags 293076 + upstream
tags 293076 + fixed-upstream
retitle 293076 [fixed in 3.4] g++-3.3: uninformative error when base class
missing
thanks
Greg Kochanski <[EMAIL PROTECTED]> writes:
> In the following program, the base class is missing.
> G++ gives a wimpy error message:
>
> bug.c:3: error: p
Greg Kochanski <[EMAIL PROTECTED]> writes:
>> Which seems like an acceptable error message. Unfortunately, it is
>> rather likely that this gets fixed in 3.3, too.
>
> How about this variant that defines inverse() ?
> [...]
Hmm. This seems like valid code, but g++ 3.3 still rejects it.
However, t
Hi,
this bug does not occur with gcc 3.0 from Debian, so it can be closed
as soon as we make 3.0 standard.
Falk
Package: g++-3.0
Version: 1:3.0.1-0pre010811
Severity: normal
File: /usr/bin/g++-3.0
[EMAIL PROTECTED]:~/src/yucata% g++-3.0 -c -mcpu=k6 -O2 bug.ii
bug.cc: In function `int alphaBetaWithMemory(Board, bool, int, int, int)':
bug.cc:128: Unrecognizable insn:
(insn 1671 141 1672 (parallel[
Hi,
I just noticed I can't reproduce this bug after rebooting, so it was
likely caused by bad RAM or something. If you can't reproduce it, too,
we can just close it.
Falk
Package: gcc-3.0
Version: 1:3.0.3-1
Severity: normal
Hi,
[EMAIL PROTECTED]:~% cat bug.c
struct descr {
int len;
char data[];
};
int foo() {
struct descr s1 = { 3, "FOO" };
}
[EMAIL PROTECTED]:~% /usr/bin/gcc-3.0 bug.c
bug.c: In function `foo':
bug.c:6: Internal error: Segmentation fa
Tyson Whitehead <[EMAIL PROTECTED]> writes:
> > please reuse the original report. Falk has to approve it anyway.
>
> Done deal. Just awaiting Falk now.
Patch looks OK, except
++DEBIAN SPECIFIC: This option is on by default, unless
[EMAIL PROTECTED] (which is part of the @option{-ffast-math}
++
tags 228018 + upstream
thanks
Joe Nahmias <[EMAIL PROTECTED]> writes:
> gcc -Wall -g -O2 -Wall -Winline -DOPENGL -DFRAMESKIP -DSTDIOIFACE \
> -DUNIXDSP -DNETWORK -DFPS `sdl-config --cflags` -Izlib \
> -fomit-frame-pointer -DSDL -DUNIX -DPSS_STYLE=1 -DZLIB -c -o x6502.o \
> x6502.c
> x6502.c: I
Falk Hueffner <[EMAIL PROTECTED]> writes:
> It takes about 2.5G to compile. gcc-snapshot (3.4) is not better. An
> older tree-ssa snapshot I happend to have lying around however only
> takes about 130M, so it's probably a RTL optimizer going haywire.
Today's 3.4 takes 4
Markus Rechberger <[EMAIL PROTECTED]> writes:
> When I put a constant infront of methods in a class the application
> uses to segfault. When I put it at the end the application just
> works as expected.
Sorry, I don't understand. Please file a bug with a complete example
to reproduce the problem.
Probably related to gcc PR 14166. There's a patch for that here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14166
--
Falk
[EMAIL PROTECTED] (Joe Nahmias) writes:
> FWIW, I just tried to compile on escher with:
>
> $gcc --version
> gcc (GCC) 3.3.3 20040125 (prerelease) (Debian)
>
> no good. I guess I'll have to wait until 3.4 is uploaded.
I'll build it on my own machine with some extra swap files.
--
Fal
Michael Weitzel <[EMAIL PROTECTED]> writes:
> g++ - compiler crashes when compiling a huge (>30 MB), auto-generated
> source file (differential equation system). The reported error message
> was:
>
> DynamicSystem_PPP_realPool.cxx:530334: internal compiler error: in
>final_scan_insn, at final
Marc Deichmann <[EMAIL PROTECTED]> writes:
> I compiled the following c code with g++/gcc 2.95/3.2/3.3 on different
> stable/unstable Debian systems with 2.4/2.6 kernels (also
> Athlon/Opteron/Pentium). On every system the result was the same.
>
> int main(void) { double a[200]; int b = 1;
Jason Dorje Short <[EMAIL PROTECTED]> writes:
> Further information:
>
> I can reproduce this crash, if I compile the file four times
> simultanously. And I can reproduce it without using ccache.
Nearly certainly you're running out of memory. Please check that with
top.
--
Falk
Mark Cox <[EMAIL PROTECTED]> writes:
> I am interested in packaging ghdl (http://ghdl.free.fr) for debian, but I'm a
> little unsure on how to go about it.
>
> The README contained in the source file states that I must place a directory
> as a subdirectory of the gcc tree and evoke ./configure o
[EMAIL PROTECTED] (Debian Bug Tracking System) writes:
> Processing commands for [EMAIL PROTECTED]:
>
>> severity 236291 important
> Bug#236291: FTBFS on hppa architecture
> Severity set to `important'.
Can you please send a *complete* test case?
--
Falk
On Wed, 31 Mar 2004, Oswald Buddenhagen wrote:
> this is new in gcc/g++ 3.3.3-5; it worked in 3.3.3-3 (i think, not
> sure about the -3 part).
>
> the following minimal test program triggers an endless loop (it should
> exit immediately):
>
> --
> #include
>
> static struc
tags 241255 +fixed-upstream
thanks
A patch by Jakub Jelinek has been approved, so this should be fixed
next time CVS is pulled.
--
Falk
Marcin Kurek <[EMAIL PROTECTED]> writes:
> I am not completly shure is that a real bug
but mark it important just in case, right?
> it seems __attribute_const__ cause a parse error in current Debian
> release. And such construction can be found in many kernel 2.6.4
> header files and in some pro
Roberto Salles <[EMAIL PROTECTED]> writes:
> cout << "long long double: " << sizeof(long long double) << '\n';
> long long double: 8
>
> Is that what to expect of long long double?
There is no "long long double"; the compiler should reject the
code. g++ apparently misparses this as "long lon
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> Package: gcc-3.3
> Version: 3.3.3-6
>
> Some package fail to build on amd64 with this error:
> /usr/include/c++/3.3/x86_64-linux/bits/atomicity.h:40: error: inconsistent
>operand constraints in an `asm'
Can you provide a preprocessed test case?
--
Clint Adams <[EMAIL PROTECTED]> writes:
>> The string stored at ptr, after ptr is no longer equal to optr, changes
>> from "" to "\020" when checkunary() is called. I'm going to try again
>> with gcc -O0 to see if the same thing happens.
>
> The test passes with no optimization; I guess this mean
"Art Haas" <[EMAIL PROTECTED]> writes:
> Compiling the 2.6.7-rc1 kernel with the latest gcc-3.3 causes a problem.
>
> gcc -Wp,-MD,mm/.fremap.o.d -nostdinc -iwithprefix include -D__KERNEL__
> -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs
> -fno-strict-aliasing -fno-common -m32 -pipe -mno-fp
Here's a smaller test case:
static __inline__ __attribute__ ((always_inline))
int page_mapping (unsigned flags)
{
if (1u & (flags >> 16))
return 1;
return 0;
}
void install_page (unsigned flags)
{
if (__builtin_expect (!page_mapping (flags), 0))
__builtin_trap ();
}
--
Fal
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> Package: gcc-3.3
> Version: 3.3.3-9
>
> A preprocessed file says:
> # 213 "/usr/lib/gcc-lib/x86_64-linux/3.3.3/include/stddef.h"
> typedef long unsigned int size_t;
>
> This seems to work, and it's probably valid too, but I've never
> seen it written that
Christophe Delage <[EMAIL PROTECTED]> writes:
> A program of mine compiles 8 (eight) times slower with this version
> than with 3.3.3-1. The problem is also present in 3.3.3-8, I don't
> have time to dichotomize and find out what exact version the problem
> appeared in.
Please provide a preproces
201 - 250 of 250 matches
Mail list logo
