Hi, all
Can anyone help me to resolve this problem?
When I compile a program with .bss segement larger than 2.0GB, I get the
following error message from GNU linker (binutils-2.15).
(.text+0x305): In function `sta_':
: relocation truncated to fit: R_X86_64_32S plot_
..
I upgrade the
Hi,
On a quick look ---
My apologies if this message doesnt seem appropriate on this list.
gcc-help list is appropriate for such issues.
_handle = dlopen( ./libchrcv.so, RTLD_NOW | RTLD_GLOBAL );
Have you tried with any other library or only this ? I tried the entire
program with a
Rohit Arul Raj wrote:
Hi all,
I have 3 functions- fun1, fun2, fun3 in the same source file and i
want to enable one or any of the gcc optimization pass to code in fun2
only,
1. Is it possible to implement this using function attributes or #pragms's?
I believe that currently, tuning
Richard Smith [EMAIL PROTECTED] writes:
| About five years ago, I reported a bug about an ICE when
| trying to mangle expressions involving operator new.
|
| http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
|
| A three line example
On Thu, 26 Jul 2007, Diego Novillo wrote:
I've always found the term Non-Autopoiesis too pretentious and
unnecessarily complex. In a recent thread, Tobias Schluter proposed
Non-autonomous, which is at least more readily understandable.
Disclaimer: I am writing this in my capacity as
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes:
On Wed, Jul 25, 2007 at 02:29:26PM +1000, Ben Elliston wrote:
If you build the compiler with coverage instrumentation and run the
testsuite, you might get a shock. It's not as well tested as you might
think.
For example, several
Diego Novillo writes:
Diego I've always found the term Non-Autopoiesis too pretentious and
Diego unnecessarily complex. In a recent thread, Tobias Schluter proposed
Diego Non-autonomous, which is at least more readily understandable.
Diego Would this patch be OK? Any other suggestions for a
Ian Lance Taylor [EMAIL PROTECTED] writes:
tm.texi does not require that NO_REGS == 0,
Um, yes? Unless you're assuming that the user could do NO_REGS=5 or
something in the enum, so that the enum starts with something other
than zero? If that's what you're thinking, perhaps we should change
David Edelsohn wrote:
Diego Novillo writes:
Diego I've always found the term Non-Autopoiesis too pretentious and
Diego unnecessarily complex. In a recent thread, Tobias Schluter proposed
Diego Non-autonomous, which is at least more readily understandable.
Diego Would this
Doug Gregor wrote:
Now, we're saying that any expressions are valid in
sizeof, decltype, and constant expressions. If those
expressions fail to type-check during substitution, it
will be a SFINAE case.
Just to be sure we're not talking at cross purposes, can I
check that the current thinking
David Daney [EMAIL PROTECTED] writes:
Between gcc@ and gcc-help@ I think we have it pretty much covered. I
have not really seen anyone flamed on gcc@ when they ask newbie type
questions related to GCC development.
I think the risk is not so much that people get flamed, as that they
get
Gabriel Dos Reis wrote:
On Wednesday July 18, 2007 I brought factual evidence to
that claim by showing g++ behaviour on all of the examples
discussed (including those from the decltype proposal).
(All I did was to encode call expressions, new expressions
and a few other tree nodes).
I'm
Joe Buck [EMAIL PROTECTED] writes:
I think that when we do steer someone to a different list, we could
take more care to be polite about it than we sometimes are.
I agree. I also think we should all try harder to avoid flippant or
non-responsive replies to new developers. I think it's
On 7/26/07, Diego Novillo [EMAIL PROTECTED] wrote:
I would like to propose the creation a new mailing list:
[EMAIL PROTECTED]
The purpose of this list is to attract and help new GCC developers who
might feel lost and intimidated by the more arcane traffic at gcc and
gcc-patches. In this
Diego Novillo [EMAIL PROTECTED] writes:
I would like to propose the creation a new mailing list:
[EMAIL PROTECTED]
Hi! I'm new at gcc. How do I compile C programs? Can I use it to
write video games?
The purpose of this list is to attract and help new GCC developers
Oh, is that what this
Hi Jan.
What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
/* ??? It is possible to create extern inline function and later using
weak alias attribute to kill its body. See
gcc.c-torture/compile/2009-1.c */
if (!DECL_SAVED_TREE (decl))
DJ Delorie [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
tm.texi does not require that NO_REGS == 0,
Um, yes? Unless you're assuming that the user could do NO_REGS=5 or
something in the enum, so that the enum starts with something other
than zero? If that's what
I've always found the term Non-Autopoiesis too pretentious and
unnecessarily complex. In a recent thread, Tobias Schluter proposed
Non-autonomous, which is at least more readily understandable.
Would this patch be OK? Any other suggestions for a better category
name? Is anyone violently
Hi Richard,
On 7/26/07, Richard Smith [EMAIL PROTECTED] wrote:
About five years ago, I reported a bug about an ICE when
trying to mangle expressions involving operator new.
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
A three
About five years ago, I reported a bug about an ICE when
trying to mangle expressions involving operator new.
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
A three line example exhibiting the ICE is:
template unsigned int struct
On 26/07/07, Diego Novillo [EMAIL PROTECTED] wrote:
On 7/26/07 9:55 AM, Diego Novillo wrote:
On 7/26/07 8:21 AM, Basile STARYNKEVITCH wrote:
So currently, the answer seems to be no.
Right. It's a cool future feature, but so far nobody seems to be
working on it.
I have to retract
On 7/26/07 9:55 AM, Diego Novillo wrote:
On 7/26/07 8:21 AM, Basile STARYNKEVITCH wrote:
So currently, the answer seems to be no.
Right. It's a cool future feature, but so far nobody seems to be
working on it.
I have to retract this. On IRC I was pointed to various efforts in the
area
On 7/26/07 8:21 AM, Basile STARYNKEVITCH wrote:
So currently, the answer seems to be no.
Right. It's a cool future feature, but so far nobody seems to be
working on it.
Implementing the optimization pragmas at a function level should not be
too hard, though we may need to tweak the callgraph
On 7/26/07, Basile STARYNKEVITCH [EMAIL PROTECTED] wrote:
Rohit Arul Raj wrote:
Hi all,
I have 3 functions- fun1, fun2, fun3 in the same source file and i
want to enable one or any of the gcc optimization pass to code in fun2
only,
1. Is it possible to implement this using function
On 26 July 2007 08:30, Rohit Arul Raj wrote:
Hi all,
I have 3 functions- fun1, fun2, fun3 in the same source file and i
want to enable one or any of the gcc optimization pass to code in fun2
only,
1. Is it possible to implement this using function attributes or #pragms's?
Nope.
2.
On 26 July 2007 03:09, Dennis Clarke wrote:
The configure line for GCC 4.2.1 looks like so :
bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local
Hi all,
I have 3 functions- fun1, fun2, fun3 in the same source file and i
want to enable one or any of the gcc optimization pass to code in fun2
only,
1. Is it possible to implement this using function attributes or #pragms's?
2. What will be its side-effects?
Regards,
Rohit
Kenneth Zadeck [EMAIL PROTECTED] writes:
diego's suggestion is ok. i guess it at least satisfies the criteria of
being a well known word.
I like non-self-approving. I needed a dictionary to figure out what
autopoiesis meant.
On 7/26/07, Diego Novillo [EMAIL PROTECTED] wrote:
I would like to propose the creation a new mailing list:
[EMAIL PROTECTED]
The purpose of this list is to attract and help new GCC developers who
might feel lost and intimidated by the more arcane traffic at gcc and
gcc-patches. In this list,
On 7/26/07, Richard Smith [EMAIL PROTECTED] wrote:
Doug Gregor wrote:
This kind of thing came up that the last C++ committee meeting, as
part of core issue 339:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
Name mangling is part of the problem, but not all of it. There
The arm backend has support for both gas assembly and the syntax used by
proprietary arm assemblers (controlled by AOF_ASSEMBLER).
I'm told that the only recent users of this feature were the riscos folks, and
that they no longer care.
The only target that uses this code in the FSF tree is
Wasn't there a discussion yesterday about the fact that this is
off-topic for this mailing list? Please take this thread somewhere more
appropriate.
Thanks,
Ben
Friendly Gaurav
Build it with the -ggdb2 option, and follow those steps:
$ gdb a.out
(gdb) start
(gdb) stepi
(gdb) backtrace
(gdb) step
(gdb) bt
(gdb) stepi
(gdb) bt
(gdb) help
It's funny ;)
Hi Jan.
What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
/* ??? It is possible to create extern inline function and later using
weak alias attribute to kill its body. See
gcc.c-torture/compile/2009-1.c */
if (!DECL_SAVED_TREE (decl))
In message [EMAIL PROTECTED]
Paul Brook [EMAIL PROTECTED] wrote:
The arm backend has support for both gas assembly and the syntax used by
proprietary arm assemblers (controlled by AOF_ASSEMBLER).
I'm told that the only recent users of this feature were the riscos folks,
and
Hi, Guenther
It works. Thank you very much!
Canqun Yang
--- Richard Guenther [EMAIL PROTECTED]:
On 7/26/07, Canqun Yang [EMAIL PROTECTED] wrote:
Hi, all
Can anyone help me to resolve this problem?
When I compile a program with .bss segement larger than 2.0GB, I get the
following
[ Forgot to CC gcc@ in my initial message, thanks Andrew. ]
I would like to propose the creation a new mailing list:
[EMAIL PROTECTED]
The purpose of this list is to attract and help new GCC developers who
might feel lost and intimidated by the more arcane traffic at gcc and
gcc-patches. In
On 26 July 2007 03:09, Dennis Clarke wrote:
The configure line for GCC 4.2.1 looks like so :
bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--enable-threads=posix --disable-nls
On Thu, 2007-07-26 at 17:13 -0400, Diego Novillo wrote:
Or maybe this is not a good idea, but I have certainly seen some folks
that complain about our less than friendly practices.
Alternative would be to keep gcc@ and document that
emails with subject tag [BEGINNER] should not be answered
by
Doug Gregor wrote:
Hi Richard,
On 7/26/07, Richard Smith [EMAIL PROTECTED] wrote:
A three line example exhibiting the ICE is:
template unsigned int struct helper {};
template class T void check( helpersizeof(new T)* );
int main() { checkint(0); }
[...]
This kind of thing
On 7/26/07, Richard Smith [EMAIL PROTECTED] wrote:
template class T
class is_default_constructible {
template int struct helper {};
typedef char no; typedef char yes[2];
static no fn(...);
static yes fn( helpersizeof(new T)* );
public:
static const bool value =
SUMMARY : the stage 2 compiler produces the wrong binary type for this machine
I did further digging and built my own libiconv and installed that into my
own isolated local directory at $HOME/local
then I destroyed my previous stage 1 work and started over again thus :
bash-3.2$ date
Thu Jul
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-26 08:14 ---
Thanks Steve :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-26 07:50 ---
It might be, can you attach the preprocessed source? Which you can find by
adding -save-temps and it will be either end in .i or .ii. The difference in
glibc versions could be cause different warnings to show up
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-07-26 08:41
---
Created an attachment (id=13985)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13985action=view)
Result on avr target from GCC 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #11 from cnstar9988 at gmail dot com 2007-07-26 08:13 ---
Created an attachment (id=13981)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13981action=view)
(64bit)gcc -m32 -O3 -Wall test.c -save-temps
(64bit)gcc -m32 -O3 -Wall test.c -save-temps
In this platform, it's
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-26 08:10
---
This is a bug in glibc version you are using, the warning is comming from the
expansion of a #define. Looking at the expanded version, I see that glibc is
violating C aliasing rules anyways so the code might not
--- Comment #2 from j at uriah dot heep dot sax dot de 2007-07-26 08:39
---
Created an attachment (id=13983)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13983action=view)
Result on i386 target from GCC 3.4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #7 from burnus at gcc dot gnu dot org 2007-07-26 09:49 ---
Patch looks OK and regtests on x86-64.
That's strange - for me, it breaks ret_pointer_2.f90, at the statement print
*,
x(3) because the elements in the data transfer are incorrectly referenced.
In the
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-26 10:01
---
Well, honestly not. Still other frontends do not do return type promotion
themselves, so the backend is responsible for doing this. Do you have any
suggestion on what target to look at to verify this?
--
--- Comment #2 from tehila at il dot ibm dot com 2007-07-26 10:46 ---
(In reply to comment #2)
Just want a clarification:
I see you're compiling on PPU (since you're using -maltivec).
Does this problematic also on SPU? Does SPU has this LHS hazard?
Another question:
lwz r0,-20(r1)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-26 10:33 ---
Maybe related to PR32891.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rask at gcc dot gnu dot org 2007-07-26 09:33 ---
Reopening since this was only partially fixed.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-07-26 08:40
---
Created an attachment (id=13984)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13984action=view)
Result on i386 arch from GCC 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-26 09:14 ---
Subject: Bug 32843
Author: rguenth
Date: Thu Jul 26 09:13:58 2007
New Revision: 126950
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126950
Log:
2007-07-26 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from cnstar9988 at gmail dot com 2007-07-26 08:20 ---
I want the warning.
but why the warning is glibc's bug?
because memset(x,19,0), is buggy code.
I need the warning.
--
cnstar9988 at gmail dot com changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-26 09:20 ---
(In reply to comment #5)
This fixes the PR but is not regtested:
Patch looks OK and regtests on x86-64.
That's strange - for me, it breaks ret_pointer_2.f90, at the statement print *,
x(3) because the elements in
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2007-07-26
09:23 ---
Fixed by:
http://gcc.gnu.org/viewcvs?view=revrevision=126942
r126942 | ian | 2007-07-26 04:27:34 +0400 (Thu, 26 Jul 2007) | 7 lines
* combine.c (combine_max_regno): Remove. Remove all uses.
--- Comment #7 from cnstar9988 at gmail dot com 2007-07-26 07:45 ---
test.c:14: warning: statement with no effect
So I think it is gcc warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
--- Comment #4 from pluto at agmk dot net 2007-07-26 10:53 ---
(In reply to comment #3)
Maybe related to PR32891.
sip-qt problems == PR30052
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32900
--- Comment #5 from drs at nrao dot edu 2007-07-26 14:48 ---
I have exactly the same problem with gcc 4.2.1 on a powerpc osx system:
oz:~/bug root# gcc -DMONOLITH -I. -fPIC -fno-common -DOPENSSL_PIC -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -DB_ENDIAN -c
-o
There is a typo in libjava/classpath/gnu/java/security/util/Base64.java's
decode function.
public static byte[] decode(final byte[] src, final int off, final int len)
{... }
The following loop ends up throwing an exception on correct input.
A continue line is missing, as shown below.
When the
--- Comment #8 from belyshev at depni dot sinp dot msu dot ru 2007-07-26
19:48 ---
Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus
java) with patch from comment #6 on alphaev56-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-26 19:52 ---
Created an attachment (id=13987)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13987action=view)
testcase
Whoops - I have boot headers installed!? Try again.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from chris at bubblescope dot net 2007-07-26 19:41 ---
Ah, woops, many apologises. Too long since I've looked at list::size, I forgot
which way around libstdc++ differed from the rest of the world :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-26 20:21 ---
Created an attachment (id=13988)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13988action=view)
preprocessed testcase (trunk)
Note preprocessed source is incompatible wrt different gcc versions and so
useless
The frontend creates a tree gfc_c_int_type_node in multiple places, to
represent integers the same size as C int. This is unnecessary, as the same
thing is found in the tree integer_type_node defined by the middle-end.
Assigning this to myself.
--
Summary: Replace
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-26 22:16 ---
Currently fighting namelists ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dmixm at marine dot febras dot ru 2007-07-27 01:24
---
Yes, results are:
avr-gcc-3.3.6: O0 -- 75, O1,O2,O3,Os -- 79
avr-gcc-4.2.1: O0 -- 109, O1,O2,O3,Os -- 79
The mistake is corrected? It is possible to tell and so as now
application of keys of optimization
--- Comment #6 from scovich at gmail dot com 2007-07-26 22:51 ---
I've observed several more pieces of code where this bug comes up, and it
always seems to be a case of (a) the compiler duplicating a register to
preserve the value after a 2-operand insn can clobbers the original, then
--- Comment #9 from falk at debian dot org 2007-07-26 22:49 ---
(In reply to comment #8)
Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus
java) with patch from comment #6 on alphaev56-unknown-linux-gnu.
So, are you going to post the patch to gcc-patches?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
--
chris at bubblescope dot net changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
lexicographical_compare is used to implement operator and friends on all
containers. The code is not optimised for random_access iterators, where we can
find which list is the longest before starting and save one comparison every
loop.
Replace the following line:
for (; __first1 != __last1
--- Comment #1 from pault at gcc dot gnu dot org 2007-07-26 19:27 ---
(In reply to comment #0)
The problem looks similar to PR31205 in so far that gfortran did the
Tobias,
This PR is caused by the patch for pr31205. If you reference x1 in set, for
example by another print, it works
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-26 18:22 ---
Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
Also, it requires boost :)
On 7/26/07, Daniel Berlin [EMAIL PROTECTED] wrote:
Preprocessed source please.
I don't make installed
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #4 from sje at cup dot hp dot com 2007-07-26 17:19 ---
Fix is checked in.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #21 from zadeck at naturalbridge dot com 2007-07-26 17:35
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
Seongbae Park (???, ???) wrote:
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This patch extends the fix in
program test_gfortran
implicit none
!test case 1, similar to PR26074
integer, parameter :: len = 1
integer, parameter :: arr(max(len,1)) = (/1/)
!test case 2
character(len=*), dimension (1), parameter :: specStr =
--- Comment #11 from sje at cup dot hp dot com 2007-07-26 16:44 ---
Sorry, I missed the fact that it was a regression. I will test the 4.2 branch
and then backport it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
--- Comment #9 from sje at cup dot hp dot com 2007-07-26 16:30 ---
The fix for this was approved and checked into mainline.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-07-26 15:02
---
Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from manu at gcc dot gnu dot org 2007-07-26 13:57 ---
(In reply to comment #12)
I want the warning.
but why the warning is glibc's bug?
Andrew already tried to explain. It is a side-effect of a bug in glibc.
because memset(x,19,0), is buggy code.
I need the
--- Comment #19 from zadeck at naturalbridge dot com 2007-07-26 11:51
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
This patch extends the fix in
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html
to handle the case of clobbers inside conditional calls.
This
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-26 09:58 ---
Confirmed. This is caused by
2007-04-17 Mark Mitchell [EMAIL PROTECTED]
PR c++/31513
* call.c (convert_for_arg_passing): Convert bitfields to their
declared types.
which causes us to
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-26 09:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-26 07:42 ---
can gernerate warning on gcc-4.2.1 on x86
What is the warning? Because I am not seeing it.
It might be that glibc is doing the warning. Can you paste the warning you are
getting?
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot
|dot org
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-26 21:19 ---
PR 32596 is the ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-26 20:02 ---
This is fixed by:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 126885)
+++ gcc/fortran/trans-decl.c(working copy)
--- Comment #1 from pcarlini at suse dot de 2007-07-26 19:35 ---
Well, in our current, C++03, implementation, definitely list::size is O(N). The
issue is thorny, as you know well. For C++0x, Howard has a proposal related to
the additional splice overload, I'm not sure which is the
This is picked up from http://gcc.gnu.org/ml/gcc/2007-07/msg00681.html ,
apologises if it has already been dealt with.
Both std::string and std::list do not compare lengths before comparing elements
in operator==. In std::string this increases the chances of quitting early and
produces a small
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-26 18:21 ---
Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
Preprocessed source please.
I don't make installed versions of the compiler to play with :)
On 25 Jul 2007 11:46:35 -, rguenth at
--- Comment #22 from seongbae dot park at gmail dot com 2007-07-26 17:56
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Seongbae Park (???, ???) wrote:
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This
F95, 5.4 Namelist Statement, 1st Constraint:
A namelist-group-object shall not be [...] a pointer, a variable of a type
that has an ultimate component that is a pointer [...].
This code is accepted by gfortran-20070725:
TYPE :: tt
INTEGER, POINTER :: x
END TYPE
TYPE(tt) :: t
NAMELIST /nl2/ t
--- Comment #14 from pinskia at gmail dot com 2007-07-26 16:51 ---
Subject: Re: warning for memset with zero size
On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
I think that is a sensible feature request, am I missing something Andrew?
memset
--- Comment #10 from pluto at agmk dot net 2007-07-26 16:37 ---
(In reply to comment #9)
The fix for this was approved and checked into mainline.
resolved/fixed? what about 4.2 branch? it's a regression.
--
pluto at agmk dot net changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2007-07-26 16:19 ---
Note that this is fixed in Classpath and gcj 4.3.
As I recall, Casey (? I think) consolidated all the Base64
implementations into a single good one.
--
tromey at gcc dot gnu dot org changed:
What
1 - 100 of 123 matches
Mail list logo
