--- Comment #2 from pault at gcc dot gnu dot org 2006-09-18 07:49 ---
This fixes it:
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 117013)
--- gcc/fortran/resolve.c (working copy)
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #10 from lopezibanez at gmail dot com 2006-09-18 08:16 ---
Yes, I hope to get it into 4.3. Nonetheless, if you wish to test it, I can add
the patch here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
--- Comment #2 from oschmidt at gmx dot net 2006-09-18 08:35 ---
> default operator= with lhs and rhs as the same.
if it would be the operator= this would be ok. But it's the default copy
constructor that is called withed lhs and rhs the same and such an object with
undefined content is
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-09-18 08:44 ---
Subject: Re: IV selection is messed up
> On 17 Sep 2006 22:48:12 -, rakdver at gcc dot gnu dot org
> <[EMAIL PROTECTED]> wrote:
> > Regarding the "-fprefetch-loop-arrays's heuristic is way
The gcc compiler for arm could not be created due to an assember error:
- Host compier:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1
--includedir=/usr/lib/gcc/i686-p
--- Comment #3 from oschmidt at gmx dot net 2006-09-18 08:47 ---
> > So which version do you think have a bug?
>
> I don't know which behaviour should be correct C++, but I think it is
> dangerous
> that an object with undefined content is constructed without even a compiler
> warning.
Hi,
I noticed that the CPU_TIME intrinsic subroutine is
implemented only for real(4) and real(8) arguments,
but real(10) is missing for i386, and probably similar
versions for other architectures.
Cheers,
-ha
--
Summary: CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #1 from anlauf at gmx dot de 2006-09-18 08:56 ---
Created an attachment (id=12290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12290&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-09-18 09:16
---
Subject: Bug 27226
Author: rguenth
Date: Mon Sep 18 09:16:16 2006
New Revision: 117018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117018
Log:
2006-09-18 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-09-18 09:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #3 from paolo at gcc dot gnu dot org 2006-09-18 09:19 ---
Subject: Bug 29063
Author: paolo
Date: Mon Sep 18 09:19:36 2006
New Revision: 117019
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117019
Log:
2006-09-18 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from pcarlini at suse dot de 2006-09-18 09:20 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
gcc -O3 test.c --ipa-cp -m64
test.c:
#include
int
bar (int b, int c)
{
printf ("%d %d\n", b, c);
}
int
foo (int a)
{
if (a++ > 0)
bar (a, 3);
foo (7);
}
int
main ()
{
foo (7);
return 0;
}
=
,fortran
Thread model: posix
gcc version 4.2.0 20060918 (experimental)
/usr/local/4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1plus -quiet -v
-D_GNU_SOURCE testTypedefFriend.cpp -quiet -dumpbase testTypedefFriend.cpp
-mtune=generic -auxbase testTypedefFriend -version -o /tmp/cc79A4Nh.s
ignoring nonex
$ cat tmp.c
struct some_struct
{
int i;
int j;
void* priv[];
};
struct some_struct_priv
{
int k;
int l;
};
void update( struct some_struct* s )
{
s->i = 0;
s->j = 0;
struct some_struct_priv* priv = (struct some_struct_priv*)s->priv;
#i
In 3.3.3 and GCC svn as of June. Unbuildable since then.
int a (unsigned int n)
{
struct c
{
int d[n];
} e;
return e.d[0];
}
--
Summary: Failure to diagnose violation of constraint 6.7.5.2p2
Product: gcc
Version: 4.2.0
Status: UNCONFIRM
In 3.3.3 and GCC svn as of June. Unbuildable since then.
int f (unsigned int m)
{
extern int (*b)[m];
return (*b)[0];
}
--
Summary: Failure to diagnose violation of constraint 6.7.5.2p2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-09-18 10:07 ---
I say this should be made invalid. In fact we already warn about it to become
invalid:
./cc1 -quiet t.c
t.c: In function 'ldt_add_entry':
t.c:3: warning: use of memory input without lvalue in asm operand 0 is
depre
--- Comment #1 from razya at il dot ibm dot com 2006-09-18 10:09 ---
The ICE is due to a call to a versioned function that IPCP triggered.
The call instruction is corrupted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29122
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-09-18 10:13
---
Subject: Bug 28900
Author: rguenth
Date: Mon Sep 18 10:13:42 2006
New Revision: 117021
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117021
Log:
2006-09-18 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-09-18 10:14
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #13 from uros at gcc dot gnu dot org 2006-09-18 10:15 ---
Subject: Bug 28946
Author: uros
Date: Mon Sep 18 10:14:53 2006
New Revision: 117022
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117022
Log:
PR target/28946
* config/i386/i386.md ("*ashldi3_c
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-18 11:36
---
> Hmmm, seems this is a known issue that never got fixed. See this thread:
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01558.html
And this one: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01569.html
--
e
--- Comment #11 from mueller at gcc dot gnu dot org 2006-09-18 12:11
---
yes please. Actually I created my own patch for bringing the C++ frontend on
ear with the C frontend, but I didn't submit it because it produced bazillions
of (legal) warnings in the code I usually compile, too man
--- Comment #12 from lopezibanez at gmail dot com 2006-09-18 12:22 ---
Created an attachment (id=12291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12291&action=view)
wcoercion patch r116922
Patch for trunk revision 116922 (bootstrapped and tested on i686-pc-linux-gnu).
--
gnatchop breaks when invoked with a name that includes a hyphen, or if the
command is symlinked to such a name:
$ /usr/bin/gnatchop-4.1 support/checkfil.ada
gnatchop-gcc: installation problem, executable not found
no source files written
$ ls -l /usr/bin/gnatchop
lrwxrwxrwx 1 root root 12 2006-09-
--- Comment #13 from lopezibanez at gmail dot com 2006-09-18 12:45 ---
(In reply to comment #11)
> yes please. Actually I created my own patch for bringing the C++ frontend on
> ear with the C frontend, but I didn't submit it because it produced bazillions
> of (legal) warnings in the co
I get the following on ia64, but not on e.g. x86_64.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 erlang-beam_emu.c
erlang-beam_emu.c: In function 'process_main':
erlang-beam_emu.c:28: internal compiler error: in move_block_after_check, at
haifa-sched.c:4337
Please submit a full bug r
--- Comment #1 from tbm at cyrius dot com 2006-09-18 13:38 ---
Note that this code was affected by PR28489 and while the fix for this PR fixed
the other testcases, this shows the current, new ICE.
--
tbm at cyrius dot com changed:
What|Removed |Add
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-18
13:39 ---
Subject: Re: [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution
test
> And this one: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01569.html
Actually, I was thinking that the library name sho
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-18 13:48
---
> + /* TER is not run at -O0, so our representation of alignment
> + information and its propagation is non-existant. */
> + if (!optimize)
> +return 0;
Perhaps
if (!flag_tree_ter)
return 0;
wo
--- Comment #6 from tbm at cyrius dot com 2006-09-18 13:50 ---
Note that this bug is very frequent (compiling the Debian archive).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
--- Comment #1 from neil at gcc dot gnu dot org 2006-09-18 14:02 ---
Fixed in current SVN.
--
neil at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #1 from neil at gcc dot gnu dot org 2006-09-18 14:02 ---
Fixed in current SVN.
--
neil at gcc dot gnu dot org changed:
What|Removed |Added
Status|
Compile the following with -std=c99 -pedantic-errors
void f(unsigned int [*]);
foo.c:1: error: '[*]' not allowed in other than a declaration
--
Summary: Strictly conforming code rejected
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Seve
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-18 14:33 ---
And this is a regression because...?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-18 14:34 ---
Because of PR28489. Right.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from neil at gcc dot gnu dot org 2006-09-18 15:13 ---
Confirmed
--
neil at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-03-05 0
I am trying to link some code and I get the following from the link step:
collect2: ld terminated with signal 11 [Segmentation fault]
/usr/bin/ld: build/x86-64.linux/gcc64/cc-O2/clientTest.o: bad relocation
section name `'
I can make this happen with either -O2 or -g compiled code. If I comment o
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-09-18
15:29 ---
This is still better and even regtests!
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (révision 116697)
--- gcc/fortran/
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-18 15:32 ---
Subject: Bug 29087
Author: steven
Date: Mon Sep 18 15:32:43 2006
New Revision: 117026
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117026
Log:
PR c++/29087
* parser.c (cp_parser_labeled_stat
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-09-18
15:33 ---
I mixed up my types above; using a gfc_array_index_type seems to
cover every circumstance where missing arguments can be addressed
with legal code.
Regtests on FC5/Athlon.
Index: gcc/fortran/trans-decl.
--- Comment #7 from micis at gmx dot de 2006-09-18 15:39 ---
I get the same ICE with this short code:
class A;
class B
{
typedef void (*C[5]) (A *);
static C D;
static void E (A*) {}
};
B::C B::D={E};
--
micis at gmx dot de changed:
What|Removed
I am using gcc3.3.5 on solaris2.7. Its a 64 bit compilation
I am compiling a file 'plugin.cpp'. It includes mach.h and the complation
gives the following error.
-
mach.h error: conflicting
types for `typedef vx_u32_t off32_t'
/
--- Comment #9 from steven at gcc dot gnu dot org 2006-09-18 15:42 ---
Fix for GCC 4.1 coming later today.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from laguest at archangeli dot demon dot co dot uk
2006-09-18 16:11 ---
Seems this was an error based on the use of a limited view of a type. I don't
know whether this is actually allowed in the Ada 2005 standard, i.e passing a
reference to a limited view to a container?
The following C++ code should not compile:
template
int t(T i)
{
return f (i); // error: f not visible here
}
int
f (int i)
{
return i;
}
int
main()
{
return t(1);
}
The C++ standard clause 14.6.3 states that names should be looked up from the
point they are used. I.e. functions defined
--- Comment #4 from patchapp at dberlin dot org 2006-09-18 17:15 ---
Subject: Bug number PR29101
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00715.html
--
http://gcc.gnu.org/bugzilla/sh
On Mon, 2006-09-18 at 13:48 +, ebotcazou at gcc dot gnu dot org
wrote:
>
> --- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-18 13:48
> ---
> > + /* TER is not run at -O0, so our representation of alignment
> > + information and its propagation is non-existant. */
>
--- Comment #8 from pinskia at physics dot uc dot edu 2006-09-18 17:19
---
Subject: Re: [4.2 Regression] FAIL:
gcc.dg/torture/pr26565.c -O0 execution test
On Mon, 2006-09-18 at 13:48 +, ebotcazou at gcc dot gnu dot org
wrote:
>
> --- Comment #7 from ebotcazou at gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 17:20 ---
See comment #6 in PR 864, this is a known bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29128
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 17:23 ---
collect2: ld terminated with signal 11 [Segmentation fault]
That means a bug in binutils and not in GCC.
Report this first to redhat since that is where you got your binutils and GCC.
--
pinskia at gcc dot gnu do
--- Comment #2 from jmbnyc at gmail dot com 2006-09-18 17:24 ---
Subject: Re: bad relocation section name
thanks, will do.
/JMB
On 18 Sep 2006 17:23:33 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #1 from pinskia at gcc dot gnu dot org 2006-0
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 17:28 ---
(In reply to comment #0)
> The C++ standard clause 14.6.3 states that names should be looked up from the
> point they are used. I.e. functions defined after that point are not visible.
> This is true for regular func
--- Comment #3 from laurent at guerby dot net 2006-09-18 17:55 ---
Confirmed.
$ gcc -c -gnat05 test_observers.adb
+===GNAT BUG DETECTED==+
| 4.2.0 20060915 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
atree.adb:812|
| Error
--- Comment #3 from jmbnyc at gmail dot com 2006-09-18 17:58 ---
Subject: Re: bad relocation section name
FYI:
I think I found the source of the problem. I am using boost::bind to
create a function pointer to an object. If my class does not have a
default constructor then I get the pr
--- Comment #1 from laurent at guerby dot net 2006-09-18 17:59 ---
Confirmed on GNAT 4.2.0 20060915 (experimental)
Classifying as enhancement request.
--
laurent at guerby dot net changed:
What|Removed |Added
---
--- Comment #2 from laurent at guerby dot net 2006-09-18 18:12 ---
Hi Andreas, could you try this patch? If this works I'll submit it, if not
please let me know what's the next blocking point.
--- osint.adb.orig 2006-09-18 20:05:30.0 +0200
+++ osint.adb 2006-09-18 20:08:3
--- Comment #1 from laurent at guerby dot net 2006-09-18 18:15 ---
Indeed (4.1 and 4.2), Arnaud I assume it's a matter of importing?
--
laurent at guerby dot net changed:
What|Removed |Added
-
--- Comment #1 from laurent at guerby dot net 2006-09-18 18:29 ---
Confirmed on gcc version 4.2.0 20060915 (experimental)
$ ./bind_socket_bug
Socket bound to: 0.0.0.0: 53558
Connecting to: 127.0.0.2: 53558
Accepted connection from: 127.0.0.2: 36739
With the following patch:
--- g-sock
--- Comment #2 from laurent at guerby dot net 2006-09-18 18:30 ---
Arnaud, any socket expert comment on my patch above?
--
laurent at guerby dot net changed:
What|Removed |Added
--
--- Comment #1 from laurent at guerby dot net 2006-09-18 18:43 ---
Asynchronous abort is implementation defined here since there is no abort
completion point in your loop.
You can make this works portably by adding a "delay 0.0;" statement within your
loop, see ARM 9.8(18).
--
laure
--- Comment #3 from janis at gcc dot gnu dot org 2006-09-18 19:23 ---
A regression hunt on powerpc-linux using the testcase from comment #2
identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=116468
r116468 | mmitchel | 2006-08-26 16:23:33 + (Sat, 26 Aug 2006)
--- Comment #3 from schwab at suse dot de 2006-09-18 19:29 ---
That didn't change anything.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29127
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-18 19:29 ---
Thanks Steven, it was just too obvious, wasn't it?
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c(revision 117030)
+++ gcc/fortran/
--- Comment #8 from pault at gcc dot gnu dot org 2006-09-18 20:20 ---
Subject: Bug 28526
Author: pault
Date: Mon Sep 18 20:19:50 2006
New Revision: 117034
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117034
Log:
2006-09-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/28
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-18 20:20 ---
Subject: Bug 29101
Author: pault
Date: Mon Sep 18 20:19:50 2006
New Revision: 117034
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117034
Log:
2006-09-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/28
The combination of GCC (r116604 or later) and binutils-2.17 creates bad
.eh_frame data causing SIGSEGV at runtime anytime an exception is thrown.
To reproduce just run the g++ testsuite. All exception tests FAIL.
This problem is discussed further in:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg
--- Comment #28 from geoffk at gcc dot gnu dot org 2006-09-18 21:02 ---
The current version of the documentation says, for -fvisibility=,
Be aware that headers from outside your project, in particular system
headers and headers from any other library you use, may not be
expecting to be
--- Comment #1 from roger at eyesopen dot com 2006-09-18 21:27 ---
Hi David,
I was wondering if you have a MIPS tree handy, whether you could easily
test the following single line patch:
Index: dwarf2out.c
===
*** dwarf2ou
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-18 21:32 ---
The patch also went into the 4.1 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ddaney at avtrex dot com 2006-09-18 21:32 ---
Subject: Re: [4.2 Regression] Mips exception handling broken.
roger at eyesopen dot com wrote:
> --- Comment #1 from roger at eyesopen dot com 2006-09-18 21:27 ---
> Hi David,
>
> I was wondering if you have a
--- Comment #4 from ddaney at avtrex dot com 2006-09-18 21:59 ---
Subject: Re: [4.2 Regression] Mips exception handling broken.
roger at eyesopen dot com wrote:
> --- Comment #1 from roger at eyesopen dot com 2006-09-18 21:27 ---
> Hi David,
>
> I was wondering if you have a
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-18 22:02 ---
Subject: Bug 28817
Author: pault
Date: Mon Sep 18 22:02:24 2006
New Revision: 117038
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117038
Log:
2006-09-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from pault at gcc dot gnu dot org 2006-09-18 22:02 ---
Subject: Bug 29060
Author: pault
Date: Mon Sep 18 22:02:24 2006
New Revision: 117038
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117038
Log:
2006-09-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from pault at gcc dot gnu dot org 2006-09-18 22:02 ---
Subject: Bug 21918
Author: pault
Date: Mon Sep 18 22:02:24 2006
New Revision: 117038
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117038
Log:
2006-09-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from laurent at guerby dot net 2006-09-18 22:04 ---
(sorry to be guessing, but I don't understand much of what this code is doing.)
Here is another try (probably breaks cross tools, but if it works at least we
know where the problem lies):
--- osint.adb.orig 2006-09
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-18 22:24 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pault at gcc dot gnu dot org 2006-09-18 22:25 ---
integer, allocatable :: x(:)
integer :: i, j(2)
allocate (x(kind(i)), stat=i)
print *, size(x)
allocate (x(size(j)), stat=j(1))
print *, size(x)
end
--
pault at gcc dot gnu dot org changed
--- Comment #10 from pault at gcc dot gnu dot org 2006-09-18 22:26 ---
Fixed on trunk and 4.1
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28526
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-18 22:35 ---
Not fixed just yet.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #12 from eweddington at cso dot atmel dot com 2006-09-18 22:42
---
(In reply to comment #11)
> Created an attachment (id=12115)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12115&action=view) [edit]
> When relocated do not add paths that contain the configured prefix.
--- Comment #11 from sayle at gcc dot gnu dot org 2006-09-18 22:56 ---
Subject: Bug 4520
Author: sayle
Date: Mon Sep 18 22:56:44 2006
New Revision: 117042
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117042
Log:
PR middle-end/4520
Backport from mainline
I'm using the special GCC that Apple supplies with
Mac OS X 10.4.7 (PowerPC) and XCode 2.4. I just ran
a test case with code like:
std::deque d;
assert( d.max_size() <= d.get_allocator().max_size() );
And it failed. I looked at the definition of deque::max_size
and saw that it blindly return s
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 23:12 ---
And what does the C++ standard say about this case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
--- Comment #2 from pcarlini at suse dot de 2006-09-18 23:26 ---
(In reply to comment #1)
> And what does the C++ standard say about this case?
As far as I can see, the standard is very vague about the relationship between
the two max_size. About allocator::max_size, it says "the larges
--- Comment #1 from fang at csl dot cornell dot edu 2006-09-18 23:38
---
Motion to dupe as PR 21498.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29123
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-18 23:42
---
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1520.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-18 23:42 ---
*** This bug has been marked as a duplicate of 21498 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-18 23:42
---
*** Bug 22047 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-18 23:42 ---
*** This bug has been marked as a duplicate of 21498 ***
*** This bug has been marked as a duplicate of 21498 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-18 23:42
---
*** Bug 29123 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-18 23:42
---
*** Bug 29123 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-19 03:12 ---
Here is a reduced testcase:
int
bar (int b, int c)
{
return 0;
}
int
main ()
{
bar (8, 4);
return bar (7, 4);
}
-
This is due to tail calls.
> The call instruction is corrupted.
No, it is not, it is correc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4520
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 03:21 ---
I cannot reproduce this with "4.2.0 20060311" or 4.0.3 or 4.1.0 20060208.
Are you sure that you don't have a patch that causes problems?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29124
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 03:24 ---
Confirmed, a regression from 4.1.2 which we accepted this but gave a warning
saying we don't implement the semantics yet. Since we accepted this with a
warning before and now reject it, I am going to say this is a r
1 - 100 of 131 matches
Mail list logo
