--- Comment #4 from domob at gcc dot gnu dot org 2008-10-04 06:45 ---
Created an attachment (id=16461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16461&action=view)
Patch addressing most of the "specific" remarks
This patch (posted to the list some time ago) addresses most of t
--- Comment #7 from jifl-bugzilla at jifvik dot org 2008-10-04 02:54
---
To avoid any uncertainty, I arranged a copyright assignment. Unfortunately the
FSF's copyright clerk left and there was a gap before the replacement started,
but it just so happens that today he confirmed the assig
--- Comment #1 from siarhei dot siamashka at gmail dot com 2008-10-04
02:48 ---
For -Os optimization, the generated code is much better:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 53 push %ebx
For the following source:
//
extern void a();
int unrolled_loop_fn(int count)
{
while ((count -= 2) >= 0) {
a();
a();
}
if (count & 1) {
a();
}
}
//
'gcc -O2 -c test.c' produces
--- Comment #8 from hjl dot tools at gmail dot com 2008-10-04 01:33 ---
(In reply to comment #7)
> This regression was introduced between 2005-03-11 and 2005-03-13.
> This patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01296.html
>
> may be the cause.
>
It is the cause. This
--- Comment #7 from hjl dot tools at gmail dot com 2008-10-04 01:06 ---
This regression was introduced between 2005-03-11 and 2005-03-13.
This patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01296.html
may be the cause.
--
hjl dot tools at gmail dot com changed:
Wha
--- Comment #32 from rguenth at gcc dot gnu dot org 2008-10-04 00:57
---
As we PHI-translate k_1 * 4 we are not able to find D.1237_7 * 4 in the
SCCVN tables. So we allocate a new value-id for it. Oops. This is because
once we say its type is unsigned int and once it's unsigned long.
--- Comment #31 from pinskia at gcc dot gnu dot org 2008-10-04 00:13
---
the reduced testcase in comment #30 is optimized by DOM3 though not by PRE.
Running PRE again right after the first PRE still founds more PREable
expressions for this testcase ...
--
http://gcc.gnu.org/bugzill
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-10-03 23:54
---
Comment #6 still applies. On the trunk we do not fully exploit the partial
redundant load of array[k] in
if (k < j)
if (array[k] < array[k + 1L])
++k;
if (array[i] < array[k])
b
--- Comment #29 from rguenth at gcc dot gnu dot org 2008-10-03 23:18
---
*** Bug 37732 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-03 23:18 ---
*** This bug has been marked as a duplicate of 21485 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #28 from rguenth at gcc dot gnu dot org 2008-10-03 23:18
---
nbench 2.2.3 numeric sort test executes 40% less iterations per second
when compiled with 4.4 snapshot than with 3.4.6
iterations/s - version
2439 - 3.4.6
1530 - 4.4.0 20080926 (experimental)
1526 - 4.3.2
1580 -
--- Comment #6 from paolo dot carlini at oracle dot com 2008-10-03 23:06
---
Ralf, any feedback on this issue? Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-03 22:56
---
Fixed.
*** This bug has been marked as a duplicate of 30085 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #15 from paolo dot carlini at oracle dot com 2008-10-03 22:56
---
*** Bug 36893 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from simartin at gcc dot gnu dot org 2008-10-03 22:53
---
Introduced by a new gcc_assert (wrapped in ENABLE_CHECKING) in the fix for
PR35056 (this assert was discussed starting from
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00181.html)
--
simartin at gcc dot gnu do
--- Comment #6 from hjl dot tools at gmail dot com 2008-10-03 22:47 ---
Gcc 4.0.4 works.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to work
--- Comment #2 from wbrana at gmail dot com 2008-10-03 22:47 ---
(In reply to comment #1)
> Dup of PR21485?
>
PR21485 is ignored by reporter and doesn't have updated summary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37732
--- Comment #6 from paolo dot carlini at oracle dot com 2008-10-03 22:42
---
Benjamin, any feedback on this? Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
--- Comment #3 from JFTrudeau at cvty dot com 2008-10-03 22:36 ---
(In reply to comment #1)
> What is your stack size limit set to?
>
/mtg/arc$ /usr/bin/ulimit -a
time(seconds)unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes)4194304
m
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-03 22:36 ---
Dup of PR21485?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|
--- Comment #2 from JFTrudeau at cvty dot com 2008-10-03 22:34 ---
Created an attachment (id=16460)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16460&action=view)
Complete transcript of failed bootstrap
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37733
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-03 22:30 ---
What is your stack size limit set to?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37733
build/genattr /mtg/arc/gcc-4.3.2/gcc/config/rs6000/rs6000.md \
insn-conditions.md > tmp-attr.h
/mtg/TOOL/powerpc-AIX5.2/bin/bash /mtg/arc/gcc-4.3.2/gcc/../move-if-change
tmp-attr.h insn-attr.h
echo timestamp > s-attr
/mtg/arc/gcc-4.3.2-powerpc-AIX5.2/./prev-gcc/xgcc
-B/mtg/arc/gcc-4.3.2-p
nbench 2.2.3 numeric sort test executes 40% less iterations per second
when compiled with 4.4 snapshot than with 3.4.6
iterations/s - version
2439 - 3.4.6
1530 - 4.4.0 20080926 (experimental)
1526 - 4.3.2
1580 - 4.2.4
CFLAGS = -s -static -Wall -O3 -g0 -march=nocona -fomit-frame-pointer
-funroll-
--- Comment #13 from dominiq at lps dot ens dot fr 2008-10-03 22:23 ---
> Happily, I have come to the conclusion that the code is invalid no matter
> which
> order the declarations come in;
>
> (a) a restricted expression or
> (b) a variable whose properties inquired about are not
--- Comment #5 from hjl dot tools at gmail dot com 2008-10-03 22:00 ---
Gcc 3.4.6 works.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to work
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-03 21:47 ---
2.95 and 3.3.6 work.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-03 21:43 ---
Confirmed. HWI32 issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-03 21:40 ---
Oh this works fine on x86-darwin because HWI is 64bits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-03 21:39 ---
One more reason to use HWI as 64bits on x86-linux-gnu :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
On Linux/ia32, gcc 4.4 gave:
[EMAIL PROTECTED] longlong-2]$ cat y.c
#include
extern void abort ();
unsigned long long xh = 1ull;
int
main ()
{
unsigned long long yh = 0xull;
unsigned long long z = xh * yh;
unsigned long long i = 1ull * yh;
printf ("%llx\n", i);
printf ("%llx
--- Comment #4 from spop at gcc dot gnu dot org 2008-10-03 21:11 ---
Bug is fixed in graphite branch. Waiting review for trunk.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from spop at gcc dot gnu dot org 2008-10-03 21:10 ---
Subject: Bug 37684
Author: spop
Date: Fri Oct 3 21:09:37 2008
New Revision: 140861
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140861
Log:
2008-10-03 Harsha Jagasia <[EMAIL PROTECTED]>
PR tree-op
--- Comment #21 from luisgpm at linux dot vnet dot ibm dot com 2008-10-03
20:59 ---
It fixes the bzip2 ICE.
Thanks,
Luis
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-03 20:56 ---
(In reply to comment #1)
> Works correctly on the trunk, that is it does not warn at all.
Well with -pedantic it does warn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37653
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-03 20:46 ---
In the private case, A is a non-POD so _c can fit tail part of A. So the
sizeof(M) is 16 bytes.
In the public case, A is a POD so _c is not allowed to be in the tail part of A
(as required by the C++ standard), so t
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-10-03 20:41 ---
I have a patch which I am testing right now:
Index: c-typeck.c
===
--- c-typeck.c (revision 140850)
+++ c-typeck.c (working copy)
@@ -3994,7 +3994,7 @
--- Comment #3 from spop at gcc dot gnu dot org 2008-10-03 20:38 ---
This bug is different than PR37485. It still fails in the graphite branch.
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-03 20:30 ---
Most likely a dup of bug 31849.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37678
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-03 20:29 ---
Confirmed. At first sight this looks like an expansion problem of the
initializer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from spop at gcc dot gnu dot org 2008-10-03 20:28 ---
*** Bug 37587 has been marked as a duplicate of this bug. ***
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from spop at gcc dot gnu dot org 2008-10-03 20:28 ---
This bug will be fixed when the patches for PR37485 will be in trunk.
The bug is fixed in the graphite branch.
Sebastian
*** This bug has been marked as a duplicate of 37485 ***
--
spop at gcc dot gnu dot org cha
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37657
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
Since on x86-darwin, SSE2 is enabled by default, I see a failure with this
testcase:
output
is:/Users/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/pr37713.c:
In function 'add_opush':^M
/Users/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/pr37713.c:8:
internal compiler error
--- Comment #19 from sebpop at gmail dot com 2008-10-03 20:15 ---
Subject: Re: [4.4 Regression] Building of CPU2000's bzip2 with peak flags with
-mcpu=power4 fails with an ICE.
Here is a patch that should fix this bug. Can somebody test that it fixes it?
Thanks,
Sebastian
--- C
Here is a patch that should fix this bug. Can somebody test that it fixes it?
Thanks,
Sebastian
Index: tree-loop-linear.c
===
--- tree-loop-linear.c (revision 140668)
+++ tree-loop-linear.c (working copy)
@@ -333,11 +333,16 @@ linear
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-03 19:35 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-03 18:57 ---
Subject: Bug 37726
Author: jakub
Date: Fri Oct 3 18:55:39 2008
New Revision: 140857
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140857
Log:
PR debug/37726
* gimplify.c (declare_vars): Use g
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-03 18:56 ---
I thought there was a defect report (against the C standard) about this but I
can't find the bug which was referencing that one.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37725
In this testcase:
int f(int,int);
template
auto g(T... parms) -> decltype (f(parms...));
int main()
{
return g(1,2);
}
We deduce the template argument types properly, but substituting them into the
return type fails because retrieve_local_specialization doesn't find a function
argument pack
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-03 18:46 ---
*** This bug has been marked as a duplicate of 18770 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-03 18:46 ---
*** Bug 37728 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
for this too but I am too lazy right now to find it.
>
> $ ./xgcc -B./ -c t.cc
> $
>
> they expected this to produce a redeclaration error on the inner
> declaration
> for X.
>
> Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision
> 140855]
> (GCC)
>
&
x = 0) {
int x;
}
}
This is invalid C++ but it is valid C99. There is already a duplicated
bug filed for this too but I am too lazy right now to find it.
$ ./xgcc -B./ -c t.cc
$
they expected this to produce a redeclaration error on the inner
declaration
for X.
Tested on gcc versio
declaration
for X.
Tested on gcc version 4.4.0 20081003 (experimental) [trunk revision 140855]
(GCC)
There were other concerns about for, but, others seem to think gcc does the
right thing with them.
--
Summary: if scoping for declarations
Product: gcc
Version
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-03 17:54 ---
Should be fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #20 from pinskia at gmail dot com 2008-10-03 17:34 ---
Subject: Re: Segmentation fault
Sent from my iPhone
On Oct 3, 2008, at 1:38 AM, "ivranos at freemail dot gr"
<[EMAIL PROTECTED]
> wrote:
>
>
> --- Comment #9 from ivranos at freemail dot gr 2008-10-03 08:38
--- Comment #3 from pinskia at gmail dot com 2008-10-03 17:33 ---
Subject: Re: "initialization from incompatible pointer type" does not say
which field is being initialized
Sent from my iPhone
On Oct 3, 2008, at 5:51 AM, "rguenth at gcc dot gnu dot org"
<[EMAIL PROTECTED]
> wrote:
Sent from my iPhone
On Oct 3, 2008, at 1:38 AM, "ivranos at freemail dot gr" <[EMAIL PROTECTED]
> wrote:
--- Comment #9 from ivranos at freemail dot gr 2008-10-03 08:38
---
I am sorry but you are not right/specific.
At first there is no struct in the code, only class.
In C+
--- Comment #1 from joseph at codesourcery dot com 2008-10-03 17:00 ---
Subject: Re: New: NO_IMPLICIT_EXTERN_C for newlib
I've argued before and will argue again that NO_IMPLICIT_EXTERN_C should
be the default with a macro IMPLICIT_EXTERN_C defined for only those
targets known to ne
--- Comment #30 from sherpya at netfarm dot it 2008-10-03 17:06 ---
the patch looks ok but unfortunately does not always solves the problem,
something in the chain misalignes the symbol
This does not happen always but in some circumstances :(
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #29 from nickc at redhat dot com 2008-10-03 16:54 ---
Created an attachment (id=16458)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16458&action=view)
Revised patch which handles (size == 0)
--
nickc at redhat dot com changed:
What|Removed
--- Comment #28 from nickc at redhat dot com 2008-10-03 16:52 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi Danny,
> This test case:
> t1.c:(.text+0x5): undefined reference to `_i'
Hmm, I cannot reproduce this, however...
>
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-03 16:31
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo at gcc dot gnu dot org 2008-10-03 16:30 ---
Subject: Bug 37719
Author: paolo
Date: Fri Oct 3 16:29:07 2008
New Revision: 140855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140855
Log:
/cp
2008-10-03 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
Is there any reason that NO_IMPLICIT_EXTERN_C can't be automatically defined,
if --with-newlib is used? newlib's headers are C++-safe.
--
Summary: NO_IMPLICIT_EXTERN_C for newlib
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: triv
--- Comment #18 from spop at gcc dot gnu dot org 2008-10-03 15:49 ---
Mine.
We should do exactly what graphite is doing: register loops belonging
to the loop nest in a VEC, then iterate over the loop nest to find the
index in the Access Matrix.
--
spop at gcc dot gnu dot org changed
--- Comment #6 from aran at 100acres dot us 2008-10-03 14:53 ---
There is a typo in the last path. Apply this after the above.
--- orig/gcc/ada/s-osinte-netbsd.adb2008-10-03 07:50:29.0 -0700
+++ netbsd/gcc/ada/s-osinte-netbsd.adb 2008-10-02 19:35:38.0 -0700
@@ -46,
--- Comment #8 from James dot W dot Mckelvey at jpl dot nasa dot gov
2008-10-03 14:16 ---
Last night I tried to bootstrap with Windows in safe mode. It got past the
"cannot create executables" and went on to fail with a different error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
int foo (int parm)
{
int var = 0;
int bar (void)
{
return parm + var;
}
parm++;
var++;
return bar ();
}
int
main (void)
{
return foo (4) - 6;
}
at -O0 -g this was perfectly debuggable in 4.3, but doesn't know anything about
parm or var, neither in the outer nor inner function.
--- Comment #19 from paolo dot carlini at oracle dot com 2008-10-03 13:21
---
Before anything else, you should realize that, per 23.1/3, the type of objects
stored in a std::vector must meet the requirements of CopyConstructible types
(20.1.3), which, in turn, include semantic requireme
--- Comment #11 from paolo dot carlini at oracle dot com 2008-10-03 13:00
---
Brian is right:
http://gcc.gnu.org/mirrors.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
--- Comment #10 from pdemarco at ppg dot com 2008-10-03 12:53 ---
(In reply to comment #9)
> Subject: Re: Spurious 'might be used uninitialized'
> warnings in STL headers with -O2
> You are confusing the state of the Cygwin port of gcc with gcc in
> general.
Possibly, but I cannot fi
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-03 12:51 ---
patches welcome ;)) Indeed, this would be nice to fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from pault at gcc dot gnu dot org 2008-10-03 12:12 ---
(In reply to comment #11)
Happily, I have come to the conclusion that the code is invalid no matter which
order the declarations come in;
In a restricted expression... (7.1.6.2):
(7) A reference to an intrinsic func
--- Comment #18 from ivranos at freemail dot gr 2008-10-03 11:59 ---
The last two code snippers had errors.
--
ivranos at freemail dot gr changed:
What|Removed |Added
--- Comment #17 from ivranos at freemail dot gr 2008-10-03 11:55 ---
The bug occurs in this simpler code too:
#include
#include
#include
#include
#include
int main()
{
using namespace std;
vector intVector(1000*1000);
srand(time(0));
for(size_t i= 0; i< numer
--- Comment #16 from ivranos at freemail dot gr 2008-10-03 11:52 ---
I managed to replicate the bug in simple code:
#include
#include
#include
#include
int main()
{
using namespace std;
vector intVector(1000*1000);
srand(time(0));
for(size_t i= 0; i< RAND_MAX;
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-03 10:56 ---
Please read the standard, particularly ISO C99 in 6.7.8/23 says:
"The order in which any side effects occur among the initialization list
expressions is unspecified." 130)
"130) In particular, the evaluation order nee
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-03 10:54
---
Any news Ed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34419
--- Comment #6 from paolo dot carlini at oracle dot com 2008-10-03 10:53
---
This is now fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from andy-gcc at ultra-premium dot com 2008-10-03 10:52
---
Gah. You are absolutely correct. Thanks for your help, and I'm glad I included
this sentence:
"And sorry if my understanding of the extended assembly is wrong and this is a
bug in my own code."
--
http://gc
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-03 10:51
---
Then, I guess we can just assign to Jason.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
test case:
#include
typedef struct {
unsigned int a;
unsigned int b;
unsigned int c;
unsigned int d;
} Head;
void f()
{
unsigned int offsetVar=sizeof(Head);
Head h={
1,
2,
offsetVar,
offsetVar+=sizeof(unsigned int)
};
printf("%d\t%d\t%d\t%d\n", h.a, h.b, h.c,
--- Comment #15 from ivranos at freemail dot gr 2008-10-03 09:54 ---
So, if there isn't any source code bug at my side, and it is a compiler bug,
you mean "the maintainers" don't care to fix it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37721
--- Comment #14 from paolo dot carlini at oracle dot com 2008-10-03 09:20
---
You can re-open it, unfortunately we cannot avoid it, at the moment, but given
that you are doing it against the judgement of the maintainers, nobody will pay
any further attention to it, ever. Be warned.
--
--- Comment #13 from ivranos at freemail dot gr 2008-10-03 09:09 ---
The prurpose of the code is to benchmark the sorting of a vector and of a list
with complex objects as their elements (SomeClass).
SomeClass itself doesn't make any other sense, its purpose is to be complex.
I think t
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #12 from paolo dot carlini at oracle dot com 2008-10-03 08:52
---
Good. In general, please don't try to force the GCC maintainers to debug user
code, this is not going to work. And, by the way, Andrew is right, your class
SomeClass appears badly broken in many different ways
--- Comment #11 from ivranos at freemail dot gr 2008-10-03 08:48 ---
I posted the code to c.l.c++ with the subject "Segmentation fault". If noone
finds any bug, I will reopen the bug here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37721
--- Comment #10 from paolo dot carlini at oracle dot com 2008-10-03 08:41
---
To be clear: in general PRs are not meant to be re-opened by submitter at will,
unless he provides at the same time additional, detailed evidence going beyond
the initial report. Debug-mode cannot be wrong. Pl
--- Comment #9 from ivranos at freemail dot gr 2008-10-03 08:38 ---
I am sorry but you are not right/specific.
At first there is no struct in the code, only class. Second, the copy
constructor does not copy the passed argument, it ignores it. But it
initialises its data member the same
98 matches
Mail list logo
