Sent from my iPhone
On Feb 4, 2010, at 2:48 AM, "rearnsha at gcc dot gnu dot org" > wrote:
--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-02-04
10:48 ---
Created an attachment (id=19803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803&action=view)
Possible pa
On Jul 15, 2010, at 2:15 AM, "cm1 at mumac dot de" > wrote:
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I edited the contents of the precompiler output to make it
more readable
and messed up the auto variable name. Please use this code:
#include
#includ
This is expected and iirc required by the c++ standard too.
On Jul 15, 2010, at 8:51 AM, "hubicka at gcc dot gnu dot org" > wrote:
Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
#include
evans:/abuild/jh/t
On Jul 20, 2010, at 7:43 PM, "rodolfo at rodsoft dot org" > wrote:
The following code doesn't compile unless variable RUNTIME is
defined as a
"static const int" instead of an "enum":
This enum value has an anonymous type which is not valid in the
context of templates in C++03/98. It is
On Aug 10, 2010, at 1:00 AM, "attardi at di dot unipi dot it" > wrote:
Code produced using -O2 handles dereferencing incorrectly.
Here is a program that shows the bug:
#include
#include
class Derived : public std::vector
{
public:
Derived() {}
};
void* foo(void* arg) {
void* basept
What about removing those in the driver? This way it works correctly
for other makefiles too?
On Aug 11, 2010, at 9:30 AM, "howarth at nitro dot med dot uc dot edu"
wrote:
Currently libjava is being improperly linked (PR java/41991) due to
the
presence of -lm and -lpthreads on the share
What version of binutils is being used?
Have you tried a newer version?
On Aug 22, 2010, at 3:11 AM, "mikael at gcc dot gnu dot org" > wrote:
Updating today at revision 163455 gave :
/home/mik/gcc46/src/libcpp/lex.c: Assembler messages:
/home/mik/gcc46/src/libcpp/lex.c:448: Error: no such inst
On Aug 25, 2010, at 5:23 AM, "socketpair at gmail dot com" > wrote:
--- Comment #7 from socketpair at gmail dot com 2010-08-25
12:23 ---
Well, I understand that problem is not in __builtin_expect.
Should I open new, separate bug about block reordering and
generating "jmp to
On Aug 31, 2010, at 8:24 AM, "yotambarnoy at gmail dot com" > wrote:
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31
15:24 ---
Good job picking up on that.
There must be a better way of telling the compiler to generate lwr
and lwl MIPS
instructions without breaki
On Aug 31, 2010, at 9:32 PM, "yotambarnoy at gmail dot com" > wrote:
--- Comment #6 from yotambarnoy at gmail dot com 2010-09-01
04:32 ---
I recently implemented a custom memcpy for ScummVM. I didn't notice
the
standard memcpy using lwl and lwr. In any case, how would memcpy do
I am not talking about a library solution at all. I am talking about a
solution inside the compiler. Gcc will optimize memcpy; how much for
MIPS is a good question. Try it out and see. Oh if you are using
scei's gcc you really should be reporting issues to them.
On Aug 31, 2010, at 10:03 PM
On Sep 1, 2010, at 10:47 PM, "ubizjak at gmail dot com" > wrote:
--- Comment #10 from ubizjak at gmail dot com 2010-09-02 05:47
---
(In reply to comment #8)
Since this doesn't backtrace in gdb, I recompiled dwarf2out.c with
the patch...
You should use bigger hammer.
Try va
You could use a small wrapper script that adds R option instead of a
specs file or adds the specs file to the command line.
On Sep 2, 2010, at 12:48 PM, "nicolai dot stange at zmaw dot de" > wrote:
Hi everybody,
I'm not involved in any gcc development nor am I familiar with gcc
and its
co
I think there is a dup of this bug without auto. Not to mention it was
defect report against the standard.
On Sep 3, 2010, at 10:07 AM, "jewillco at osl dot iu dot edu" > wrote:
The following code:
template void foo();
void f() {auto g = foo;}
fails to compile in GCC 4.5.0's C++0x mode wi
On Oct 26, 2010, at 7:30 AM, "j...@jak-linux.org" > wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #1 from Julian Andres Klode
2010-10-26 14:30:24 UTC ---
Created attachment 22162
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22162
Clang's assember
This multi
These failures have fixed already. The issue was in the testsuite.
On Nov 10, 2010, at 8:13 PM, "hjl.tools at gmail dot com" > wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46425
H.J. Lu changed:
What|Removed |Added
---
---
--
Sent from my iPhone
On Apr 28, 2010, at 6:58 PM, "cnstar9988 at gmail dot com" > wrote:
#include
#include
int main(int argc, char **argv)
{
short i = 1;
int n = (int)(i << 16);
fprintf(stderr, "%d\n", n);
return 0;
}
always 65536
it must to 0
No because short is promoted to int
Sent from my iPhone
On May 14, 2010, at 2:18 AM, "tkoenig at gcc dot gnu dot org" > wrote:
This code leads to the adding of 0.0, which is a nop. Any
signalling should have been done previously.
It is not signalling that matters here but signed zero. 0.0 + -0.0 ==
0.0. So without the 0.0
Sent from my iPhone
On May 17, 2010, at 8:37 PM, "eyakubovich at gmail dot com" > wrote:
This is a stripped down code from proposed Boost.Move library.
Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include
template
class rv : public T
{
rv();
~rv();
rv(rv const&);
This is the same problem as the other sse testcases.
Sent from my iPhone
On May 20, 2010, at 6:34 PM, "hjl dot tools at gmail dot com" > wrote:
On Linux/x86, revision 159621:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00674.html
caused
FAIL: gcc.target/i386/3dnow-1.c (internal compiler error
The naked attribute should cause two things noinline and noclone.
Sent from my iPhone
On May 29, 2010, at 4:50 AM, "rguenth at gcc dot gnu dot org" > wrote:
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-29
11:50 ---
(it seems quite stupid to have naked functions wit
I don't think this is valid. You cannot depend on where the spill will
happen around a function call. It is spilling to save the volatile
register. With -O, we don't use volatile registers to keep variables
across functions. While at -O2 we do so it saves it right before the
function call.
I think this is a dup of a much older bug.
Sent from my iPhone
On Jun 2, 2010, at 3:30 AM, "jakub at gcc dot gnu dot org" > wrote:
As mentioned in
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00115.html
for -O0 we sometimes, e.g. for return without value or for C++ NRV
optimized
return don'
Sent from my iPhone
On Jun 3, 2010, at 5:15 AM, "alexandrfedorov at gmail dot com" > wrote:
I'm trying to write windows console application working with
directories, and i
discover that arguments processed not right. For example:
#include
int main ( int argc, char *argv[], char *envp[] )
Well this code will only be compiled for arm-eabi which is an elf only
target. Please submit your patch to gcc-patc...@.
Sent from my iPhone
On Jun 7, 2010, at 9:53 PM, "raj dot khem at gmail dot com" > wrote:
--- Comment #3 from raj dot khem at gmail dot com 2010-06-08
04:53 -
Sent from my iPhone
On Jun 13, 2010, at 2:34 PM, "Daniel dot Davies at xerox dot com" > wrote:
When compiled with -03, the attached file prints out an error
message due to
incorrectly comparing "xCount + 32 < 0x8000". When compiled
with the
default optimization, it prints out the co
On Jun 16, 2010, at 9:57 AM, "gcc at razorcam dot com" > wrote:
You can't use a typedef from a typename scope in a template
This is obviously a major bug and it means you can't access the
typedefs of the
ISO standard library containers in order to use safe types to
manipulate those
conta
I bet it could be reproduced on any target with -fshort-enums.
On Jun 17, 2010, at 2:20 AM, "eblot dot ml at gmail dot com" > wrote:
--- Comment #6 from eblot dot ml at gmail dot com 2010-06-17
09:20 ---
(In reply to comment #5)
Unfortunately I don't see this happening on the x8
They were replaced with -fdefualt-integer-4/8.
On Jun 22, 2010, at 8:49 AM, "doko at ubuntu dot com" > wrote:
[forwarded from http://bugs.debian.org/582085]
"gfortran-4.4 does not support anymore the -i4 option, while
gfortran-4.3 does.
This is necessary for me to compile gildas (see
http:
On Jun 25, 2010, at 3:49 AM, "pluto at agmk dot net" > wrote:
hi,
the latest llvm/clang++ reports an error during parsing
included from :
Both of these are c++0x only headers and really are only supported
when compiling in c++0x mode.
In file included from t00.cpp:1:
In file includ
What does a break with a statement expression do for each frontend? Is
it even valid to have a break there(without a statement expression)?
If it is valid, what does each standard say about the break there? If
they say the same thing then I say both frontends should behave the
same but if the
I think the issue is we don't implement imagainy types so 1 + nan I
turns into nan.
On Jun 30, 2010, at 9:51 PM, "ian at airs dot com" > wrote:
Annex G of the ISO C99 standard says that a complex value with one
part being
infinity is considered an infinity, even if the other part is a
NaN
These functions are part of PowerPC abi. So they should be provided by
either libgcc or the libc.
On Jul 2, 2010, at 1:12 PM, "joel at gcc dot gnu dot org" > wrote:
This was spotted on powerpc-rtems but likely impacts more targets.
It is
triggered by -Os. I will attach the preprocessed fi
On Jul 6, 2010, at 7:21 AM, "andre dot bergner dot 0 at googlemail dot
com" wrote:
This is not a compiler bug, but a bug in the STL iterator class.
The less-than-operator does not work properly.
The following program can reproduce the bug.
# include
# include
using namespace std;
m
This is a dup of a much older bug which I cannot find right now.
On Jul 6, 2010, at 8:10 AM, "vincent at vinc17 dot org" > wrote:
GCC issues warnings like "division by zero" or "right shift count >=
width of
type" even though the corresponding code will never be executed
(under a
condition
Can you give the full backtrace? Where is the build2 being called from?
On Jul 9, 2010, at 7:36 AM, "bergner at gcc dot gnu dot org" > wrote:
The pr30388.c test case ICE's on trunk and powerpc64-linux with the
following
options: -Os -m64
Looking at a backtrace, we're hitting this assert in
e size of load/stores
of volatile memory.
Thanks,
Andrew Pinski
On 25 Oct 2007 19:50:54 -, Tobias dot Schlueter at physik dot
uni-muenchen dot de <[EMAIL PROTECTED]> wrote:
> I wonder why this name-mangling is necessary, it's not like these names
> are going to appear in the assembly, is it?
Those will not but other will like:
void f(void)
{
void g(void
On 27 Oct 2007 18:08:21 -, tbm at cyrius dot com
<[EMAIL PROTECTED]> wrote:
> Well, I showed that even with checking enabled the compiler was _much_ faster
> 2 months ago. But, ok, I'll try with checking disabled too.
Well someone (maybe DF) could have added a lot of checking.
-- Pinski
On 27 Oct 2007 23:16:57 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Please give this patch a try. I need it to build GCC with OpenWatcom, which
> wants parameters on the stack by default.
I think this makes some worse code in some cases. Var-args is very
bad for code generatio
On 28 Oct 2007 11:14:37 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
How many times do I have to say this is bad for most RISC targets (hosts)?
Really if the type being is used is wrong, they should be changed
rather than changing to use var-args.
-- Pinski
on=view)
> patch v3, varargs free
This version is much better.
Thanks,
Andrew Pinski
On 16 Nov 2007 18:35:15 -, ebotcazou at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> That's not true of probes in general, only of the generic implementation of
> the probing method in GCC. The implementation on Alpha/Tru64 doesn't suffer
> from this defect for example.
Or even the spu-el
> Is there any difference in the standard behaviour between printf("%s", NULL)
> and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
> but neither puts(NULL) nor fprintf(stdout, "%s", NULL) do?
No both are undefined.
-- Pinski
ss_vectorize);
{
struct tree_opt_pass **p = &pass_vectorize.sub;
NEXT_PASS (pass_lower_vector_ssa);
NEXT_PASS (pass_dce_loop);
}
Thanks,
Andrew Pinski
Sent from my iPhone
On Apr 16, 2008, at 0:07, "dimhen at gmail dot com" <[EMAIL PROTECTED]
> wrote:
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure
--prefix=/usr/local/i686-pc-linux-gnu-current
--enable-version-specific-runtime-libs --enable-
Sent from my iPhone
On Apr 17, 2008, at 12:37, "ymeroz at earthlink dot net" <[EMAIL PROTECTED]
> wrote:
Test case:
- start file bug.mm
@interface TestClass
-(void) testMethod;
@end
void ff (int& i)
{
}
@implementation TestClass
-(void) testMethod
{
int i = 1;
oth really. The way the runtime implements @throw
is via setjmp/longjmp and the compiler has to change them to volatile
variables. I told Apple not to do this but I guess they never
understood how exceptions are used.
Thanks,
Andrew Pinski
rkaound to this
> problem other than manipulating each and every file in the project?
Please read http://gcc.gnu.org/gcc-4.3/porting_to.html .
Thanks,
Andrew Pinski
On Sun, May 18, 2008 at 11:24 AM, John Kacur <[EMAIL PROTECTED]> wrote:
> int main(void)
> {
> unsigned j = ~0 >> 8;
The above is signed right shift which will keep the sign bit and replicate it.
> unsigned i = ~0;
> i >>= 8;
While this is an unsigned right shift.
-- P
On Thu, Jun 5, 2008 at 2:34 PM, hjl dot tools at gmail dot com
<[EMAIL PROTECTED]> wrote:
> There is no easy way to debug gcc compiled with -O2.
You know if you compile cc1 manually inside the gcc directory, it will
compile with -O0 -g. Also you can use stage1-gcc directory to debug
and build cc1
On Sat, Jun 7, 2008 at 5:17 PM, mt-ml at gmx dot de
<[EMAIL PROTECTED]> wrote:
> As you can see, the argument to ilog2 is urb->interval which can't be zero at
> that point IMHO.
Yes and that requires a lot of jump threading and many other
optimizations to detect that really. First PRE has to be w
On Wed, Jun 18, 2008 at 11:06 PM, Andrew McPherson
<[EMAIL PROTECTED]> wrote:
> // Neither of the following compile, though they do in visual studio.
>
> template
> struct MyStruct
> {
>MyStruct()
>{
>std::vector::iterator i;
You missed the typename keyword.
That i
mTest. template TestMe();
>}
>
> Test1 mTest;
> };
Thanks,
Andrew Pinski
This is correct as you are just using the address and not the contents
itself. This is how inline-asm is documented to work also.
-- Andrew Pinski
Sent from my iPhone
On Jun 25, 2008, at 19:08, "aoliva at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
This is origina
Sent from my iPhone
On Jul 4, 2008, at 12:01, "vincent at vinc17 dot org" <[EMAIL PROTECTED]
> wrote:
"gcc -v" output should include default values corresponding to the -
march and
-mtune options.
As a reference: http://gcc.gnu.org/ml/gcc-help/2008-07/msg00062.html
They do already via
Sent from my iPhone
On Jul 4, 2008, at 12:34, "vincent at vinc17 dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #3 from vincent at vinc17 dot org 2008-07-04 19:34
---
(In reply to comment #1)
Works if you provide an (empty) input file:
[...]
There's mtune, but not march.
This is expected as we spill all local variables to the stack for -O0.
Sent from my iPhone
On Jul 4, 2008, at 14:04, "msnkipa at mail dot ru" <[EMAIL PROTECTED]
> wrote:
So for code:
double d1 = 0;
double d2 = 1;
double d3 = 1.01;
__m128d pd, pd2;
pd = _mm_
>
> void foo (const int (*h)[2], int (*i)[2])
> {
> 1 ? h: i;
> }
>
> Also rejected in C99 mode.
ICC warns:
t.c(3): warning #42: operand types are incompatible ("const int (*)[2]" and
"int (*)[2]")
So maybe this is not valid C, I don't know.
-- Pinski
>
>
>
> --- Comment #3 from aoliva at gcc dot gnu dot org 2006-01-25 18:12
> ---
> Created an attachment (id=10728)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10728&action=view)
> Patch that disables -Wpointer-sign by default, but gets -Wall or -pedantic to
> imply it
I tho
>
>
>
> --- Comment #4 from hjl at lucon dot org 2006-01-31 00:45 ---
> This code is extracted from a much larger program. Intel FORTRAN compiler
> has no problem with it.
And what should it allocate a zero sized string?
-- Pinski
On Jan 30, 2006, at 7:45 PM, hjl at lucon dot org wrote:
Intel FORTRAN compiler has no problem with it.
Intel's Fortran compiler does not detect a lot of
invalid code, that does not make this code valid.
-- Pinski
>
>
>
> --- Comment #2 from hyperquantum at gmail dot com 2006-02-02 14:39
> ---
> IMO this is a useful feature because the number of lines of error output that
> GCC produces for a file is not (always) a correct measure for the amount of
> errors and warnings produced for that file. T
annot find it right now).
Thanks,
Andrew Pinski
ble-__cxa_atexit when configuring GCC. This
option is required to get the correct behavior of destructors.
Now you can ask why --enable-__cxa_atexit is not enabled by default
on GNU/Linux machine, I don't have that answer to that question but
someone else will.
Thanks,
Andrew Pinski
> --- Comment #5 from James dot Juran at baesystems dot com 2006-02-13
> 19:06 ---
> Yes, that does seem to be the case based on the ChangeLog I quoted. And of
> course the easy workaround for a developer is just to use __builtin_va_start
> instead. But is the deprecation of __builtin_s
On Mar 1, 2006, at 7:48 PM, Martin Sebor wrote:
Is there a recommended version of GNU binutils for 4.1? I have been
using 2.13 but the latest compiler doesn't seem to be happy with it.
I tried the latest, 2.16.1, but I get the same error with it as well.
I don't see anything about this in INSTA
On Mar 5, 2006, at 1:00 PM, hjl at lucon dot org wrote:
--- Comment #2 from hjl at lucon dot org 2006-03-05 18:00 ---
std::ios_base::_S_local_word_size is in libstdc++.so. But it is marked
as
local via linker version script. It is true for x86, x86-64 and ia64.
There is a bug in
>
>
>
> --- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 ---
> I can reproduce the runtime error, but not the compile error.
>
> pantani:/tmp/2$ type gcc
> gcc is /tmp/2/bin/gcc
> pantani:/tmp/2$ gcc a.c -fopenmp
> pantani:/tmp/2$ ./a.out
> ./a.out: error while loading
On Mar 14, 2006, at 1:55 PM, Graham Stott wrote:
All,
If the warning isn't bogus then we probably need to do the shift in
two steps
(i.e. hwi = (hwi >> (shift - 1)) >> 1) as done elsewhere to avoid the
potential warning.
The only reason why it is bogus is because well it is dead code :).
On Mar 15, 2006, at 6:28 PM, hjl at lucon dot org wrote:
--- Comment #10 from hjl at lucon dot org 2006-03-15 23:28 ---
(In reply to comment #9)
(In reply to comment #8)
Is that the exact output?
Yes, of course!
I assum you tried to compile f95files/intvec.F90. I have no probl
On Mar 16, 2006, at 6:37 PM, schwab at suse dot de wrote:
--- Comment #12 from schwab at suse dot de 2006-03-16 23:37
---
(In reply to comment #9)
Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it
works by
default?
prctl --unaligned=signal will make it gener
On Mar 16, 2006, at 7:37 PM, schwab at suse dot de wrote:
--- Comment #15 from schwab at suse dot de 2006-03-17 00:37
---
Both alpha and sparc can emulate unaligned accesses, and both set
STRICT_ALIGNMENT.
And PPC can emulate unalgined access (and does by default) and it
sets STR
On Mar 16, 2006, at 8:06 PM, schwab at suse dot de wrote:
--- Comment #17 from schwab at suse dot de 2006-03-17 01:06
---
PPC does not trap on unaligned integer load and store.
That is not true, it traps on some. It all depends on the hardware.
Please don't say it does not trap on n
On Mar 17, 2006, at 10:33 AM, Michael Tomuschat wrote:
vector >::iterator aIter; // tut nicht
You forgot the typename keyword.
It should be:
typename vector >::iterator aIter;
-- Pinski
On Mar 17, 2006, at 4:16 PM, mkuvyrkov at gcc dot gnu dot org wrote:
Unfortunately, I don't have access to HP-UX and the bug doesn't appear
on
ia64-linux, so can you please provide some more information for the
failure
like backtrace.
A cross compile will most likely reproduce it.
-- Pins
On Mar 23, 2006, at 3:06 AM, paul dot richard dot thomas at cea dot
fr wrote:
I thought to take a look at the patch tonight; does it look OK to you?
I forgot to mention, this was about the patch I was going to create
anyways.
-- Pinski
On Apr 24, 2005, at 2:06 PM, Diego Novillo wrote:
What is the type of 'i'? If it's unsigned, then we would be
wasting our time.
It is signed, otherwise "i < 0" will always be true and the conditional
would have gotten rid of already.
-- Pinski
On Apr 25, 2005, at 11:59 AM, Karl Berry wrote:
With gcc-4.0.0 on GNU/Linux (specifically, Red Hat WS 4), GNU make
3.80,
I get an error when trying to build with srcdir = objdir. Since the
documentation says this "should" work, even though it recommends
compiling with srcdir != objdir, I'm report
On Apr 25, 2005, at 11:59 AM, Karl Berry wrote:
Greetings,
In gcc-4.0.0 (and all previous releases), the C++ shared libraries (for
example) are not found without adding specific link flags. For
example,
compiling a C++ hello,world (source below, not that it matters):
$ which g++
g++ is /usr/loca
On Apr 26, 2005, at 1:37 PM, Ryszard Kabatek wrote:
Hello,
I succesfully compiled gcc-4.0.0 on RedHat, but the bootstrap fails on
Mandrake.
Yes this is a bug in your kernel headers.
-- Pinski
On Apr 26, 2005, at 2:29 PM, Bojan Antonovic wrote:
1) Similar to http://gcc.gnu.org/ml/gcc/2004-11/msg00286.html I
configured GCC to be build with
ld: .libs/libstdc++.lax/libsupc++convenience.a/tinfo2.o malformed
object, illegal reference for -dynamic code (reference to a coalesced
section (__
>
> Hello.
>
> I dont know if I am to write here, but I think I found a bug that I know
> is not related to my hardware or my system. Problem is that I don't know
> how to report it or if it allready been reported(Kind of hard to search
> for a bug when you dont know how to describe it.).
>
>
On Apr 28, 2005, at 2:41 PM, Dutta, Kalyan wrote:
I am submitting a bug report for GNU's Fortran95 compiler, gfortran.
I realize the compiler is experimental. Any help you might be able
to provide will be appreciated.
I am Emailing this report because I couldn't successfully attach the
requested p
On Apr 29, 2005, at 8:52 PM, Martin Sebor wrote:
I was surprised to see macro definitions in the output of gcc
-E -g3 (see below). Is that behavior by design or is it a bug?
(I haven't seen anything about it in the manual, other than what
-g/leve/ mentions about debugger support for macro expansion
On May 1, 2005, at 11:33 PM, belyshev at depni dot sinp dot msu dot ru
wrote:
(though profile says most of time spent in SSA verifier):
Did you forget to configure with --disable-checking :).
-- Pinski
On May 2, 2005, at 2:06 PM, Steffen Seeger wrote:
Hello everybody,
I have successfully built gcc-4.0.0 out of the release
tar-file (complete distribution) on an athlon system
targeting i386-scientific-linux.
The C and C++ parts work like a charm so far, compiling
substantial amounts of C/C++ code w
On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote:
--- Additional Comments From schlie at comcast dot net 2005-05-05
17:19 ---
(In reply to comment #2)
"unsigned char *" and "char *" are in two different aliasing sets
while char
and unsigned char are in the same one, well char
On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:
I am trying to find out where unaligned pointer is came from. Going
couple
functions back I found that it is the address if "unsigned char"
variable
allocated on stack. Should I look at this issue or it might be
possible in
theory and I shou
On May 6, 2005, at 8:09 PM, Julian Cummings wrote:
People are reporting trouble compiling blitz with gcc-4.0.0, and the
compiler errors are resulting from the use of unnamed enums. A simple
code
illustrates the problem:
struct nullType {};
template inline T operator+(const T& a, nullType) {
On May 7, 2005, at 2:04 PM, Harald Dunkel wrote:
Hi folks,
The testcase has been created by grabbing some code
fragments from libX11, XFree86 4.3 on Debian, amd64.
-Wall complains about dereferencing type-punned pointer.
Stop right there, you said it warns, well this is a case where
you are violati
On May 7, 2005, at 3:25 PM, Harald Dunkel wrote:
Andrew Pinski wrote:
Stop right there, you said it warns, well this is a case where
you are violating C89/C99/C++ aliasing rules so it is a bug in your
code and not in GCC.
This is not my code. It is XFree86 4.3. I am just trying to
help by
On May 7, 2005, at 6:40 PM, Gabriel Dos Reis wrote:
"Julian Cummings" <[EMAIL PROTECTED]> writes:
| Hmmm... I just read through the bug reports you cited. Sounds to me
like
| this is still somewhat of an open issue, as to whether the compiler
should
| issue an error in these cases or simply sile
On May 8, 2005, at 2:21 AM, Harald Dunkel wrote:
Andrew Pinski wrote:
Wrong, try again. Violating aliasing rules cause undefined behavior
so seg faulting is an okay thing to do.
But producing a warning message and bad code is not OK. Either
using a "type-punned pointer" should be tr
On May 8, 2005, at 4:17 PM, Harald Dunkel wrote:
Falk Hueffner wrote:
It doesn't know that. The warning is for the *creation* of the
type-punned pointer, which is still perfectly fine. Gcc is too stupid
to notice whether you actually dereference it.
Yup. There are billions of this constructs in eve
On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote:
* f95 disqualifies ifselves from several embedded targets, if it can
not be
built/used on targets not supporting REAL8. IIRC, there even exist
variants of
major _targets_ (IIRC, powerpc, m68k) which do not support REAL8.
IMO, thi
On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote:
* f95 disqualifies ifselves from several embedded targets, if it can
not be
built/used on targets not supporting REAL8. IIRC, there even exist
variants of
major _targets_ (IIRC, powerpc, m68k) which do not support REAL8.
IMO, thi
On May 16, 2005, at 4:28 PM, joseph at codesourcery dot com wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
2005-05-16 20:03 ---
(In reply to comment #3)
If you get rid of decl_constant_value_for_broken_optimization then I
suspect you'll lose some optimizations because
this to Apple.
This was PR 18191.
Thanks,
Andrew Pinski
Just in case you did not get this before, the mail server which I was
using
broke for a second.
Begin forwarded message:
From: Andrew Pinski <[EMAIL PROTECTED]>
Date: May 17, 2005 12:50:33 PM EDT
To: Marcel van Kervinck <[EMAIL PROTECTED]>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: (fwd)
301 - 400 of 465 matches
Mail list logo
