On 2005-07-12 23:42:23 +0200, Erik Trulsson wrote:
Pointer subtraction is only well defined if both pointers point to
elements in the same array (or one past the end of the array).
I don't know what you mean by well defined, but even in this case,
the behavior can be undefined. So, replacing a
Dave Korn wrote:
You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
and for a way to ensure correctness, I tried this
(switch register/volatile in the declaration lines in comp
and r to see the effects).
I didn't get
Paul Schlie wrote:
From: Georg Bauhaus [EMAIL PROTECTED]
Paul Schlie wrote:
From: Robert Dewar [EMAIL PROTECTED]
this would mean you could not put local variables in
registers. the effect on code quality woul be awful!
Why would anyone care about the
Hi,
I just wanted to let anyone who might interested know that there's an attempt
underway to add support for rvalue references to G++. I've got a preliminary
patch at http://russ.hn.org/rref/ which adds partial support for them, and I'm
hoping to turn it into a complete implementation over
From: Georg Bauhaus [EMAIL PROTECTED]
2) if putting local variables in registers becomes impossible
there will be a significant cost. I wanted to get an impression
of the cost. That's the reason for writing volatile in the
declaration lines. Just for demo.)
I believe that was just a
[sorry for the duplicate post, the first one somehow didn't have line breaks]
Hi,
I just wanted to let anyone who might interested know that there's an
attempt underway to add support for rvalue references to G++. I've got a
preliminary patch at http://russ.hn.org/rref/ which adds partial
Hi Russell,
Hi,
I just wanted to let anyone who might interested know that there's an attempt
underway to add support for rvalue references to G++. I've got a preliminary
patch at http://russ.hn.org/rref/ which adds partial support for them, and I'm
hoping to turn it into a complete
I know have a problem building gcc mainline with a parallel build on
Linux/x86-64:
/usr/include/java/net/URL.h:25: error: global qualification of class name is
inva
lid before ':' token
/usr/include/java/security/ProtectionDomain.h:24: error: global qualification of
class name is invalid
Andreas Jaeger [EMAIL PROTECTED] writes:
Btw. I now see a lot of these:
mkdir gnu/java/rmi/ /dev/null 21
make[3]: [gnu/java/rmi/server.lo] Error 1 (ignored)
This is rather unfortunate, it makes it difficult to grep for errors.
Can't we use something like?
@test -z gnu/java/rmi ||
Sorry for the very late response. It is actually triggered by the
bugzilla entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
The motivating example, abstracted from a misbehaving part of X, is:
void test (char *addr) {
*((volatile char *) addr);
}
In
On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
Sorry for the very late response. It is actually triggered by the
bugzilla entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
The motivating example, abstracted from a misbehaving part of X, is:
void test (char
Daniel Berlin wrote:
How does this reasoning not apply to *((char *)a) = 5 where a was
originally of a const qualified type?
Or do you think you can only *add* qualifiers, and not remove them?
Because if you allow casting away, then you can't ever trust const to be
true either, just like
object volatile).
I don't understand your point. given
void Foo (char const * a) { *(char *)a = 5; }
the compiler generates code to store 5 through the pointer 'a'. It doesn't turn
this into a call to 'abort', because it thinks you're writing to const storage.
Is this *always* the
D. Hugh Redelmeier writes:
start of Henry Spencer's comment
There is little room for compiler writers to maneuver here, unless they
have announced their intentions in advance in their documentation.
Reading C99 carefully:
...
6.3.2.1: when an object is said
Andreas Jaeger [EMAIL PROTECTED] writes:
I know have a problem building gcc mainline with a parallel build on
Linux/x86-64:
/usr/include/java/net/URL.h:25: error: global qualification of class name is
inva
lid before ':' token
/usr/include/java/security/ProtectionDomain.h:24: error:
In other words, we're asked to agree that the type of an object
changes depending on how it is accessed.
For the benefit of readers, only the first sentence of this para is
the language of the standard; the rest isn't.
That an object referred to through a volatile pointer must
Snapshot gcc-4.1-20050716 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050716/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-07-16 17:43 UTC
You'll find
On Jul 16, 2005, at 10:34 AM, Andrew Haley wrote:
6.3.2.1: when an object is said to have a particular type, the type
is
specified by the lvalue used to designate the object.
I don't have a standard here, but I will point out that IF this
sentence is
interpreted to mean
the type of an
[I'm just a tourist here. I don't subscribe to the gcc list. I don't
hack on gcc itself. I'm just posting because this bug hits me and
didn't seem to be analyzed correctly. I have participated in the C
standardization process for perhaps 20 years. Now that I look at the
GCC list archives, I
On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
Daniel Berlin wrote:
object volatile).
I don't understand your point. given
void Foo (char const * a) { *(char *)a = 5; }
the compiler generates code to store 5 through the pointer 'a'. It
doesn't turn
this into a call
Daniel Berlin [EMAIL PROTECTED] writes:
| On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
| Sorry for the very late response. It is actually triggered by the
| bugzilla entry
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
|
| The motivating example, abstracted from a
Daniel Berlin [EMAIL PROTECTED] writes:
| object volatile).
|
| I don't understand your point. given
| void Foo (char const * a) { *(char *)a = 5; }
| the compiler generates code to store 5 through the pointer 'a'. It doesn't
turn
| this into a call to 'abort', because it thinks
| There is no point in type qualifiers if they can be simply changed at
| will. Do not lie about your objects, and you will not be screwed over.
only if the language you're implementing the compiler for says so, no
matter what nifty transformation you could have done.
Except that nobody
D. Hugh Redelmeier [EMAIL PROTECTED] writes:
[...]
| - let's not talk about restrict
Oh, it was getting fun :-)
-- Gaby
Dale Johannesen [EMAIL PROTECTED] writes:
| the type of an object
| changes depending on how it is accessed.
|
| this also makes nonsense of gcc's implementation of type-based aliasing
| rules.
|
|*((int *)x) = 3
No. That one is specifically covered by the C and C++ standards
Maurizio Monge [EMAIL PROTECTED] writes:
| Hello,
| sorry for bothering you, but i wasn't able to find on the web
| the informations i was looking for about the cxx reflection branch
| and i wasn't albe to contact the mantainer (and i don't have enough
| knowlegde of gcc to deduce it from
Daniel Berlin [EMAIL PROTECTED] writes:
| | There is no point in type qualifiers if they can be simply changed at
| | will. Do not lie about your objects, and you will not be screwed over.
|
| only if the language you're implementing the compiler for says so, no
| matter what nifty
Daniel Berlin [EMAIL PROTECTED] writes:
| On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| Daniel Berlin wrote:
| object volatile).
|
|
| I don't understand your point. given
| void Foo (char const * a) { *(char *)a = 5; }
| the compiler generates code to store 5
On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
| | There is no point in type qualifiers if they can be simply changed at
| | will. Do not lie about your objects, and you will not be screwed over.
|
| only if the language you're
On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
| | There is no point in type qualifiers if they can be simply changed at
| | will. Do not lie about your objects, and you will not be screwed over.
|
| only if the language you're
On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
| On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| Daniel Berlin wrote:
| object volatile).
|
You don't make people happier by transmutating their programs into
faster
Daniel Berlin [EMAIL PROTECTED] writes:
| On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
| Daniel Berlin [EMAIL PROTECTED] writes:
|
| | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| | Daniel Berlin wrote:
| | object volatile).
| |
| You don't make people
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
| You make it sound like the standard is crystal clear on this issue, and
| everyone who disagrees with your viewpoint are just slimeballs trying to
| get around the clear wording of the standard.
I think you're profondly mistaken in your
On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
| You make it sound like the standard is crystal clear on this issue, and
| everyone who disagrees with your viewpoint are just slimeballs trying to
| get around the clear wording of
Daniel Berlin [EMAIL PROTECTED] writes:
| We both know that standards committees are not made up of 1 or 2 people,
| and saying people who designed and wrote the standard offer their view
| and interpretation of of they wrote is not useful when they do not
| actually speak for the committee.
Daniel Berlin [EMAIL PROTECTED] writes:
| On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| Daniel Berlin [EMAIL PROTECTED] writes:
|
| [...]
|
| | You make it sound like the standard is crystal clear on this issue, and
| | everyone who disagrees with your viewpoint are just
| From: Gabriel Dos Reis [EMAIL PROTECTED]
| The way I see it is that people who designed and wrote the standard
| offer their view and interpretation of of they wrote and some people
| are determined to offer a different interpretation so that they can
| claim they are well-founded to apply
D. Hugh Redelmeier [EMAIL PROTECTED] writes:
| | From: Gabriel Dos Reis [EMAIL PROTECTED]
|
| | The way I see it is that people who designed and wrote the standard
| | offer their view and interpretation of of they wrote and some people
| | are determined to offer a different interpretation so
On Sun, 2005-07-10 at 00:16 +0200, Gerald Pfeifer wrote:
On Fri, 8 Jul 2005, Daniel Berlin wrote:
Here's a patch.
Thanks.
There are a couple of commas between items missing (usually when
there is a line break)
fixed.
and some of the lines are too long (as with
GCC sources we
| From: Gabriel Dos Reis [EMAIL PROTECTED]
| After many exchanges via private mails and
| looking at the various reports related to this issue, it has become
| clear to me that the interpretations offered to justify why GCC is
| behaving the way it does seem to go beyond what can be inferred.
Richard Guenther wrote:
On 7/14/05, Richard Guenther [EMAIL PROTECTED] wrote:
As subject says - on x86_64 it takes a whopping 30 minutes to
compile said with -fprofile-generate!
It's caused by -frename-registers enabled by -funroll-loops. Compiling
with -O2 -fno-unroll-loops
On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
| From: Gabriel Dos Reis [EMAIL PROTECTED]
| After many exchanges via private mails and
| looking at the various reports related to this issue, it has become
| clear to me that the interpretations offered to justify why GCC is
|
At this point we need:
(1) agreement from C and C++ maintainers on access through volatile
lvalue
(2) agreement with the middle-end maintainers not to optimize
volatile lvalue expressions
We already don't optimize expressions considered to have volatile
operands.
It's just
Daniel Berlin [EMAIL PROTECTED] writes:
| Anything it sees anything in a statement with volatile, it marks the
| statement as volatile, which should stop things from touching it
| (anything that *does* optimize something marked volatile is buggy).
great!
| I should note that this will probably
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
| I think that is urgent.
| No offense, but everyone thinks the problems that affect them are the
| most urgent.
miscompilation of KDE was declared urgent; I hope bug affecting code
semantics for X is not just request for enhancement.
-- Gaby
On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
| I think that is urgent.
| No offense, but everyone thinks the problems that affect them are the
| most urgent.
miscompilation of KDE was declared urgent; I hope bug affecting
Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
Andrew Pinski has declared this to be a bug, but the audit trail
isn't clear as to why.
Maybe because gcc treats -O1 differently from -O2, -O3,
and -Os ? Also, since abs is a (built
| From: Gabriel Dos Reis [EMAIL PROTECTED]
| Daniel Berlin [EMAIL PROTECTED] writes:
|
| [...]
|
| | I think that is urgent.
| | No offense, but everyone thinks the problems that affect them are the
| | most urgent.
|
| miscompilation of KDE was declared urgent; I hope bug affecting code
|
Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
Daniel Berlin [EMAIL PROTECTED] writes:
| Anything it sees anything in a statement with volatile, it marks the
| statement as volatile, which should stop things from touching it
| (anything that *does* optimize something marked volatile is
D. Hugh Redelmeier [EMAIL PROTECTED] writes:
[...]
| If GCC4 causes this much problem with X, I wonder what GCC4 will do to
| the Linux kernel. I understand that Linus generally prefers older
| GCCs to newer ones. It would be great if his preference were only
| superstition.
I do not follow
Michael Veksler [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
|
| Daniel Berlin [EMAIL PROTECTED] writes:
|
| | Anything it sees anything in a statement with volatile, it marks the
| | statement as volatile, which should stop things from touching it
| |
This fails with
$ gfortran -O3 -funroll-loops elemental.f90
$ ./a.out
Aborted
Slightly reduced:
$ cat elemental-reduced.f90
! Program to test elemental functions.
program test_elemental
implicit none
integer(kind = 4), dimension (2, 4) :: a
integer(kind = 4), dimension (2, 4) :: b
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-16
09:46 ---
It fails everywhere, not just on ppc.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-07-16
09:52 ---
I guess a reduced testcase might help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-16
10:22 ---
I think that bifgel.f90 is being miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
13:50 ---
What target is this on? x86_64-pc-linux-gnu?
--
What|Removed |Added
CC|
This little code snippet compiles fine on gcc-3.x and 2.95. On 4.0 it produces
an error of conflicting
declarations of operator int to operator FooU, whereas FooU obviously is
not an int. If you
replace operator FooU with operator Bar (not being templated) it works fine
with gcc-4.0.
--
What|Removed |Added
GCC host triplet|Darwin 8.2.0 Darwin Kernel |
|Version 8.2.0: Fri Jun 24 |
|17:46:54 PD |
GCC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
14:04 ---
This works on a released version of GCC 4.0.0. Please update your compile to
the newest 4.0.0 release
(Apple already released a new version).
Also next time please check with a FSF released GCC before
Handling of -Wno-pointer-sign when used with g++ is not consistent with other C
specific warning option (at least -Wstrict-prototypes
-Wdeclaration-after-statement)
May I suggest to also emit a warning instead of an error as many people use
CXXFLAGS= $(CFLAGS) + $(c++ specific options)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
14:23 ---
Confirmed. Only a 3.4 regression.
4.0.0 and 4.0.1 (and the mainline) produces:
cc1plus: warning: command line option -Wno-pointer-sign is valid for C/ObjC
but not for C++
3.0.4 produced no warning or
--- Additional Comments From eric dot valette at free dot fr 2005-07-16
14:32 ---
Yes you are right g++ is :
g++ -v
Reading specs from /usr/lib/gcc/i486-linux-gnu/3.4.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
The programme
program real16
real*10 c
end program real16
when compiled with
GNU Fortran 95 (GCC 4.1.0 20050715 (experimental))
with
~/gcc/bin/gfortran -o real16 real16.f90 -Wall -g
leads to the error message
real16.f90: In function 'MAIN__':
real16.f90:20: internal
--- Additional Comments From schnetter at aei dot mpg dot de 2005-07-16
15:08 ---
*** This bug has been marked as a duplicate of 20120 ***
--
What|Removed |Added
--- Additional Comments From schnetter at aei dot mpg dot de 2005-07-16
15:08 ---
*** Bug 22512 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-16
16:02 ---
Subject: Bug 22421
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-16 16:01:58
Modified files:
gcc: ChangeLog c-decl.c c-pretty-print.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-16
16:04 ---
Subject: Bug 22421
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-16 16:04:38
Modified files:
gcc:
--- Additional Comments From hugh at mimosa dot com 2005-07-16 16:18
---
Here is some C Lawyering from Henry Spencer. I asked him to look at and comment
on this bug. With his permission, I'm quoting his response here.
There is little room for compiler writers to maneuver here, unless
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-16 16:35 ---
Subject: Re: gcc -O2 discards cast to volatile
hugh at mimosa dot com [EMAIL PROTECTED] writes:
[...]
| If GCC (a) wants to be C99-conforming, and (b) wants to provide useful
| semantics for
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
17:53 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
18:26 ---
Created an attachment (id=9289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9289action=view)
Shorter testcase
Less than 6kloc testcase. Reduced with delta.
--
What|Removed
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-07-16
18:59 ---
(In reply to comment #1)
What target is this on? x86_64-pc-linux-gnu?
i686-pc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
was produced by gcc version 4.0.2 20050716 (prerelease)
from the following code, using the latest ptr_list from Boost's CVS. Sorry
about the size of the .ii, the ptr_list brings in a lot of code.
#include iterator
#include cassert
#include boost/ptr_container/ptr_list.hpp
struct B { virtual ~B
--- Additional Comments From redi at gcc dot gnu dot org 2005-07-16 19:05
---
Created an attachment (id=9290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9290action=view)
Pre-processed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22513
--- Additional Comments From giovannibajo at libero dot it 2005-07-16
19:15 ---
Might be latent in HEAD
--
What|Removed |Added
CC|
Take this invalid C++ code, we ICE in force_decl_die when we supply -gdwarf-2:
namespace std {
templatetypename _Alloc class allocator;
}
namespace boost {
struct heap_clone_allocator {
};
namespace ptr_container_detail {
template class Config, class CloneAllocator struct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
19:47 ---
With -fmudflap, I get errors (many of them but this is with i686-pc-linux):
***
mudflap violation 1 (check/write): time=1121543018.141782 ptr=0xbfe049c0 size=4
pc=0xed9eb8
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-07-16 19:47 ---
Confirmed, introduced between 2005-06-08 00:20 UTC and 2005-06-09 00:20 UTC
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
19:53 ---
I think it was caused by:
+2005-06-08 Nathan Sidwell [EMAIL PROTECTED]
+
+ PR c++/19497
+ * cp-tree.def (USING_DECL): Update documentation.
+ * cp-tree.h (DECL_DEPENDENT_P): New.
+
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--
What|Removed |Added
GCC build triplet|alphaev56-unknown-linux-gnu |alphaev56-*-linux-gnu
GCC host triplet|alphaev56-unknown-linux-gnu |alphaev56-*-linux-gnu
GCC target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
20:21 ---
It works with 4.1.0 20050714.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22433
--- Additional Comments From falk at debian dot org 2005-07-16 20:25
---
I can't reproduce this with 4.1.0 20050716 on alphaev67. Can you please attach
the preprocessed source of traditional.c?
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-16
20:46 ---
Subject: Bug 13257
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-16 20:46:23
Modified files:
gcc/fortran:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
20:46 ---
Fixed by:
2005-07-13 Aldy Hernandez [EMAIL PROTECTED]
* typeck.c (build_binary_op): Adjust error message to something
more meaningful.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
20:46 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 15502 depends on bug 13257, which changed state.
Bug 13257 Summary: [4.0 only] Error instead of warning for missing comma in
format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13257
What|Old Value |New Value
--
Bug 19292 depends on bug 13257, which changed state.
Bug 13257 Summary: [4.0 only] Error instead of warning for missing comma in
format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13257
What|Old Value |New Value
I don't know exactly how much (2x?), but certainly can be faster and should just
exploit a bulky algorithm very similar to what we have for istream::getline
and getline(istream, string) - for char and wchar_t - see istream.cc. An
annoying
complication in this case is the use of ctype::is, which,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
21:00 ---
Fixed by:
2005-07-08 Geoffrey Keating [EMAIL PROTECTED]
* tree-inline.c (expand_call_inline): Prevent 'may reach end'
warning in system headers.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
21:12 ---
Hmm, I almost think this was caused by:
2005-06-08 Nathan Sidwell [EMAIL PROTECTED]
PR c++/19497
* cp-tree.def (USING_DECL): Update documentation.
* cp-tree.h (DECL_DEPENDENT_P):
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
21:15 ---
Only IA64 exception handling is broken. IA64 exceptions almost always uses
libunwind, right (even if
GCC creates the libunwind)?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
21:31 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01098.html.
Note this was introduced by the following two patches:
2005-05-31 Andrew Pinski [EMAIL PROTECTED]
* tree-cfg.c (verify_expr):
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-16
21:33 ---
Note I should give credit to Andrew Haley who pointed me to the mis compiling
of Long.toString.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22493
--- Additional Comments From hjl at lucon dot org 2005-07-16 21:36 ---
Yes. The libtool bug still exists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21071
GNU C version 4.1.0 20050716 (experimental) (alphaev68-unknown-linux-gnu)
[EMAIL PROTECTED]:/tmp% cat bug.c
void g(int x);
void f(int y2) {
int y1 = 0, dy = y2;
short sy = y2;
for (;;) {
g(y1);
while (dy) {
y1 += sy;
dy += y2
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-17
00:28 ---
Created an attachment (id=9291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9291action=view)
Treat flag_wrapv and min value in a special way
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22493
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-17
00:48 ---
Subject: Bug 21730
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-17 00:48:46
Modified files:
gcc/fortran: ChangeLog decl.c
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-17
00:56 ---
Subject: Bug 21730
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-17 00:55:59
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-17
00:56 ---
Subject: Bug 22483
Please let me know if the attached fixes it
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-17
00:56 ---
Created an attachment (id=9292)
--
1 - 100 of 101 matches
Mail list logo
