--- Comment #56 from jakub at gcc dot gnu dot org 2010-08-12 08:20 ---
Please stop wasting your and GCC developers time. As several people have
explained, your code triggers undefined behavior in C/C++, so it can do
anything at runtime. The fact that it happens to work as you expect wi
--- Comment #18 from sebastian dot huber at embedded-brains dot de
2010-08-12 08:19 ---
This bug is still present in GCC 4.6.0 20100807 (arm-eabi-gcc -O1
-fschedule-insns2 -mthumb):
readStream:
push{r4, lr}
sub sp, sp, #8
mov r4, sp
mov r
--
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 #3 from jakub at gcc dot gnu dot org 2010-08-12 09:05 ---
Subject: Bug 45259
Author: jakub
Date: Thu Aug 12 09:04:48 2010
New Revision: 163185
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163185
Log:
PR debug/45259
* caller-save.c (save_call_clobber
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-12 09:10 ---
Subject: Bug 45259
Author: jakub
Date: Thu Aug 12 09:09:49 2010
New Revision: 163186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163186
Log:
PR debug/45259
* caller-save.c (save_call_clobber
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-12 09:15 ---
Subject: Bug 45055
Author: jakub
Date: Thu Aug 12 09:14:47 2010
New Revision: 163187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163187
Log:
Backport from mainline
2010-07-30 Jakub Jelinek
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-12 09:15 ---
Subject: Bug 45137
Author: jakub
Date: Thu Aug 12 09:14:47 2010
New Revision: 163187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163187
Log:
Backport from mainline
2010-07-30 Jakub Jelinek
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-12 09:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-12 09:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from hainque at gcc dot gnu dot org 2010-08-12 09:42 ---
(In reply to comment #7)
Hi John,
> PR boehm-gc/34544
> (__gthread_active_init): Use pthread_default_stacksize_np instead of
> pthread_create to determine if hpux pthreads are active.
>
--- Comment #4 from j at uriah dot heep dot sax dot de 2010-08-12 09:54
---
(In replay to comment #1)
> That should most likely be an error instead of just a fprintf.
Agreed. What surprises me a bit that I've been under the impression
this used to work in previous releases:
[part of
--- Comment #19 from steven at gcc dot gnu dot org 2010-08-12 10:00 ---
According to comment#14, a patch from Alexander Monakov introduced this bug,
therefore:
1. this is a regression on a primary platform => priority should be set P1
--
steven at gcc dot gnu dot org changed:
--- Comment #20 from steven at gcc dot gnu dot org 2010-08-12 10:00 ---
...and
2. Add richi and amonakov to CC:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-12 10:02
---
In practice, I don't see how this issue can be tackled independently from the
complexity of erase returning iterator: adding a cache for the first non-empty
bucket is generally simple, but there is a problem wi
--- Comment #21 from steven at gcc dot gnu dot org 2010-08-12 10:08 ---
Re. comment #14 "I am a bit irritated why this bug survived the 4.4.0
and 4.5.0 release.": Yes, well, ARM maintainers have been in the CC-list for
this bug since the beginning, and apparently it was even too much tro
--- Comment #22 from amonakov at gcc dot gnu dot org 2010-08-12 10:12
---
It looks like patch from comment #16 should fix the problem, but was not
reviewed and/or applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #57 from rogerio at rilhas dot com 2010-08-12 10:16 ---
(In reply to comment #56)
> Please stop wasting your and GCC developers time. As several people have
> explained, your code triggers undefined behavior in C/C++, so it can do
> anything at runtime. The fact that it hap
--- Comment #58 from paolo dot carlini at oracle dot com 2010-08-12 10:18
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UN
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-12 10:38 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-12 10:38 ---
Subject: Bug 45232
Author: rguenth
Date: Thu Aug 12 10:38:05 2010
New Revision: 163190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163190
Log:
2010-08-12 Richard Guenther
PR tree-optimization/
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-12 10:55
---
Maybe averaging over all possible keys, we are fine: the probability to erase
the first non-empty bucket is of the order 1 / # buckets, thus decreases
exactly as fast as # buckets grows. On the average the slow
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-08-12
11:23 ---
Posted patches to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00886.html and
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00887.html. Testsuite results
posted
at http://gcc.gnu.org/ml/gcc-testresults/2010
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-12 11:37 ---
The patch from comment #16 only fixes the symptom, and only on ARM. It is not a
proper fix for the generic problem that is apparently also visible on POWER.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #24 from jakub at gcc dot gnu dot org 2010-08-12 11:47 ---
It is not visible on POWER, because it has been fixed there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-12 11:56 ---
Created an attachment (id=21468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21468&action=view)
gcc46-pr45262.patch
Untested fix.
As the testcase shows, while bar isn't miscompiled by 4.1 and earlier, foo is
m
--- Comment #25 from amonakov at gcc dot gnu dot org 2010-08-12 12:00
---
(In reply to comment #23)
> The patch from comment #16 only fixes the symptom, and only on ARM. It is not
> a
> proper fix for the generic problem that is apparently also visible on POWER.
PR30282 audit trail co
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-08-12 12:04
---
(In reply to comment #19)
> According to comment#14, a patch from Alexander Monakov introduced this bug,
> therefore:
>
> 1. this is a regression on a primary platform => priority should be set P1
It's not P1 bec
--- Comment #27 from rearnsha at gcc dot gnu dot org 2010-08-12 12:13
---
(In reply to comment #21)
> Re. comment #14 "I am a bit irritated why this bug survived the 4.4.0
> and 4.5.0 release.": Yes, well, ARM maintainers have been in the CC-list for
> this bug since the beginning, and
--- Comment #28 from jakub at gcc dot gnu dot org 2010-08-12 12:26 ---
The problem is that stuff like red-zone presence and size isn't known to the
middle-end, all that stuff is backend private, so I think the right way is to
handle this in the backends and most of the backends managed t
--- Comment #29 from rearnsha at gcc dot gnu dot org 2010-08-12 12:30
---
(In reply to comment #28)
> The problem is that stuff like red-zone presence and size isn't known to the
> middle-end, all that stuff is backend private, so I think the right way is to
> handle this in the backend
--- Comment #9 from joaquin at tid dot es 2010-08-12 12:32 ---
Hi Paolo,
My comments on your last two posts:
I think the impact of this is independent of #579: even if erase
does not return an iterator, the cached bucket pointer has to
be synced. This happens for erase(const key_type&)
--- Comment #10 from paolo dot carlini at oracle dot com 2010-08-12 12:42
---
> My comments on your last two posts:
Thanks Manuel.
> I think the impact of this is independent of #579: even if erase
> does not return an iterator, the cached bucket pointer has to
> be synced. This happe
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-12
13:38 ---
Subject: Re: pthread_default_stacksize_np failed.
Hi Olivier,
> Hi John,
> > PR boehm-gc/34544
> > (__gthread_active_init): Use pthread_default_stacksize_np instead of
> > pthread_
--- Comment #10 from dodji at gcc dot gnu dot org 2010-08-12 13:40 ---
A better patch submitted to
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00842.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-12
14:04 ---
Subject: Re: pthread_default_stacksize_np failed.
> The function is present in libc.sl on my PA HPUX 11.00 system. Possibly,
> this can be fixed by updating your libc version. However, I just noticed
>
--- Comment #11 from joaquin at tid dot es 2010-08-12 14:06 ---
> Thanks Manuel.
It's Joaquín :-) You're welcome.
> Agreed again. Now I begin to understand this issue ;) Anyway, the
> patch for our library is almost ready, already passes all my test.
> I'll apply it later today and sta
--- Comment #11 from hainque at adacore dot com 2010-08-12 14:14 ---
Subject: Re: pthread_default_stacksize_np failed.
dave at hiauly1 dot hia dot nrc dot ca wrote:
> The function is present in libc.sl on my PA HPUX 11.00 system.
Hmm, not here. There are many more pthread_ entries i
--- Comment #12 from hainque at adacore dot com 2010-08-12 14:18 ---
Subject: Re: pthread_default_stacksize_np failed.
[Thanks for your prompt feebdack Dave :-)]
dave at hiauly1 dot hia dot nrc dot ca wrote:
> It appears pthread_default_stacksize_np was added to libc in PHCO_30531
> o
--- Comment #13 from hainque at adacore dot com 2010-08-12 14:24 ---
Subject: Re: pthread_default_stacksize_np failed.
hainque at adacore dot com wrote:
> PHCO_29955 seems relevant as well
This was for 11.11. For 11.00, this is part of PHCO_29956.
--
http://gcc.gnu.org/bugzilla
With the beta AVR toolchain 3.0.0.207, the prologue for functions using a frame
has changed and is now causing stack corruption when an interrupt fires. Take
for example a function which needs 5 bytes of frame. This is how the frame is
setup in the function prologue:
Under WinAVR2010:
a30:
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-12 14:37
---
> It's Joaquín :-) You're welcome.
Sorry. I don't know what I was thinking.
> Perfect, let's do that. Regarding #579, last I heard from my contact
> in the committee is that the issue has been finally dismis
--- Comment #6 from ubizjak at gmail dot com 2010-08-12 14:46 ---
Ouch, "Here are the ration of before and after on Intel Core i7. Gzip slowed
down by 10 to 20%." [1]
Richi says: "The fix is to teach LIM to do conditional invariant motion."
Probably also related to PR42108 catch-all PR
The following code:
void bug_example_2(const char** format_address, int* ip) {
char* p1=(char*)format_address;
char* p2=(char*)ip;
int dif=p2-p1;
if (dif!=sizeof(char*)) {
// crash
char* p=0; *p=0;
}
}
void bug_example(const
--- Comment #1 from rogerio at rilhas dot com 2010-08-12 14:52 ---
Created an attachment (id=21469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21469&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #2 from rogerio at rilhas dot com 2010-08-12 14:52 ---
Created an attachment (id=21470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21470&action=view)
Compilation script
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #3 from rogerio at rilhas dot com 2010-08-12 14:54 ---
Correction:
If line "char buffer[1000]; buffer[0]=0;" _is removed then_ GCC then compiles
the code as expected and "dif" will be 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-12
15:03 ---
Subject: Re: pthread_default_stacksize_np failed.
> We probably could update our system and document but I don't know what
> to think of the more general user base (whether many could possibly be
> aff
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-12 15:08 ---
Pretty please, before filing further bugs take time and learn C.
The pointer subtraction triggers undefined behavior, because one pointer points
to one object and the other pointer points to different object.
See ISO C
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-12 15:15 ---
Why isn't this a bug in the interrupt handler?
What is "beta AVR toolchain 3.0.0.207" btw? We do not release such, so
maybe you should file a bug with the vendor releasing that?
--
http://gcc.gnu.org/bugzilla/
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-12 15:21 ---
Subject: Bug 45262
Author: jakub
Date: Thu Aug 12 15:21:34 2010
New Revision: 163193
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163193
Log:
PR middle-end/45262
* fold-const.c (make_range) :
--- Comment #5 from schwab at linux-m68k dot org 2010-08-12 15:24 ---
ISO/IEC 9899:1999, 6.9.1 Function definitions
9. Each parameter has automatic storage duration. Its identifier is an lvalue,
which is in effect declared at the head of the compound statement that
constitutes the funct
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-12 15:25 ---
Subject: Bug 45262
Author: jakub
Date: Thu Aug 12 15:25:08 2010
New Revision: 163194
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163194
Log:
PR middle-end/45262
* fold-const.c (make_range) :
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-12 15:28 ---
Subject: Bug 45262
Author: jakub
Date: Thu Aug 12 15:28:40 2010
New Revision: 163195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163195
Log:
PR middle-end/45262
* fold-const.c (make_range) :
--- Comment #6 from rogerio at rilhas dot com 2010-08-12 15:33 ---
(In reply to comment #4)
> Pretty please, before filing further bugs take time and learn C.
> The pointer subtraction triggers undefined behavior, because one pointer
> points
> to one object and the other pointer points
--- Comment #7 from rogerio at rilhas dot com 2010-08-12 15:33 ---
(In reply to comment #5)
> ISO/IEC 9899:1999, 6.9.1 Function definitions
> 9. Each parameter has automatic storage duration. Its identifier is an lvalue,
> which is in effect declared at the head of the compound statement
On Linux/x86-64, revision 163191 gave
FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original
"memcpy|(ref-all.*ref-all)" 2
FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original
"memcpy|(ref-all.*ref-all)" 2
Revision 163187 is OK. This may be caused by revision 1
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-12 15:46 ---
The pattern doesn't match even though I see two memcpy calls!?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-12 15:48 ---
(In reply to comment #1)
> The pattern doesn't match even though I see two memcpy calls!?
>
I am using
# make RUNTESTFLAGS="--target_board 'unix{-m32,}'" check
2 failures are 1 for 64bit and 1 for 32bit.
--
h
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-12 15:50 ---
I see the fails, but the pattern should still match.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from redi at gcc dot gnu dot org 2010-08-12 15:52 ---
(In reply to comment #6)
> (In reply to comment #4)
> > Pretty please, before filing further bugs take time and learn C.
> > The pointer subtraction triggers undefined behavior, because one pointer
> > points
> > to on
--- Comment #9 from schwab at linux-m68k dot org 2010-08-12 15:52 ---
The parameters contain copies of the argument values (6.9.1#10: "as if by
assignment"). The address of a parameter has no meaning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #10 from matz at gcc dot gnu dot org 2010-08-12 16:00 ---
Ahh, it's just so entertaining.
C99 is a language, cdecl a calling convention. There is no 'cdecl compiler',
it makes no sense to speak about such a thing. cdecl is a calling convention
for function written in all k
--- Comment #11 from rogerio at rilhas dot com 2010-08-12 16:04 ---
(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Pretty please, before filing further bugs take time and learn C.
> > > The pointer subtraction triggers undefined behavior, because o
--- Comment #12 from redi at gcc dot gnu dot org 2010-08-12 16:09 ---
Seriously, go away. I'll get far ruder if you're going to open bug reports
worded like this:
(In reply to comment #0)
> Don't bother trying to understand why I need the & operand to work as stated
> in
> C99, or why
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-08-12 16:09
---
>diferent types?
He did not say different types but different objects. There is a difference
between objects and types. This comes down to:
&a - &b being undefined in C90/C99/C++98/C++03/C++0x because a and b ar
--- Comment #14 from jakub at gcc dot gnu dot org 2010-08-12 16:11 ---
I never claimed p1 and p2 have different types. They have the same type.
But the standard paragraph I mentioned says:
"When two pointers are subtracted, both shall point to elements of the same
array object, or one p
--- Comment #15 from rogerio at rilhas dot com 2010-08-12 16:15 ---
(In reply to comment #14)
> I never claimed p1 and p2 have different types. They have the same type.
> But the standard paragraph I mentioned says:
> "When two pointers are subtracted, both shall point to elements of th
My code, which previously compiled with GCC 4.3 and 4.4 with -m32 as well as
for 64 bit, fails to compile with GCC 4.5.[01] when compiling for 32 bit
(-m32).
I tried to reduce the problem to a minimal testcase and arrived at this:
typedef int __v4si __attribute__ ((__vector_size__ (16)));
typedef
--- Comment #16 from redi at gcc dot gnu dot org 2010-08-12 16:17 ---
(In reply to comment #15)
>
> char* p1=random_address();
> char* p2=another_random_address();
>
> p1-p2 is always well defined, no matter to which objects they point to.
No. No it isn't. It really isn't.
(In reply
--- Comment #17 from rogerio at rilhas dot com 2010-08-12 16:18 ---
(In reply to comment #12)
> Seriously, go away. I'll get far ruder if you're going to open bug reports
> worded like this:
> (In reply to comment #0)
> > Don't bother trying to understand why I need the & operand to wor
--- Comment #18 from rogerio at rilhas dot com 2010-08-12 16:18 ---
You know what? I did a small sample showing this bug to other people. They all
understood it, but not you. They all know what it means C99+cdecl at the same
time. You don't. I'm surprised at your lack of capacity for ude
--- Comment #19 from redi at gcc dot gnu dot org 2010-08-12 16:20 ---
Everyone understands it, you're just wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-12 16:44 ---
I was wrong. Linux/ia32 has the same regression:
FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original
"memcpy|(ref-all.*ref-all)" 2
--
hjl dot tools at gmail dot com changed:
What
--- Comment #20 from dj at redhat dot com 2010-08-12 16:57 ---
Just for fun, I compiled this test case with various levels of optimization.
It works fine without optimization or with -O1, but segfaults at -O2 or -O3.
That indicates that the program only works by coincidence, not by des
--- Comment #21 from froydnj at gcc dot gnu dot org 2010-08-12 17:08
---
Even without optimization (as the compilation script uses), the program
crashes. To be concrete about what's going wrong based on what the assembly
code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5):
bu
--- Comment #22 from rogerio at rilhas dot com 2010-08-12 17:24 ---
(In reply to comment #21)
> Even without optimization (as the compilation script uses), the program
> crashes.
Right, that was the point of introducing the 1000-character buffer. With it it
crashes always.
> To be con
--- Comment #23 from rogerio at rilhas dot com 2010-08-12 17:25 ---
(In reply to comment #19)
> Everyone understands it, you're just wrong.
No I'm not, the problem seems to be just to complex for you because you would
have to tie up C99+cdecl to understand, but you don't understand it b
--- Comment #24 from rogerio at rilhas dot com 2010-08-12 17:50 ---
(In reply to comment #20)
I couldn't resist to comming back (you respond very quickly, kudos!, I'm not
used to that! :-)
> Just for fun, I compiled this test case with various levels of optimization.
> It works fine w
--- Comment #2 from darkdragon2000 at hotmail dot com 2010-08-12 17:52
---
It's not a bug in the handler since when the interrupt fires at the point when
the stack pointer is invalid (right after 0x50c), the program counter gets
pushed onto the stack, which is an invalid location.
When
--- Comment #25 from redi at gcc dot gnu dot org 2010-08-12 17:53 ---
(In reply to comment #23)
> Maybe you do a good job when you quickly send them away after stamping it with
> "non-conformant", I don't know, but I expected a little more interest on your
> part to make GCC better. I wo
--- Comment #26 from rogerio at rilhas dot com 2010-08-12 18:04 ---
> You opened this bug report with insults, what sort of response do you expect?
> GCC is too crappy and amateur for your awesome code, so I suggest you stick to
> better compilers.
Will do, thanks.
... and sorry for my
--- Comment #27 from matz at gcc dot gnu dot org 2010-08-12 18:05 ---
Oh, this fun. Enjoyable, really! ;-)
So, you admit that MSVC does in fact "miscompile" your perfectly fine cdecl
code, if you request optimization from it? How bad is that of them?
Terrible! I would consider creati
--- Comment #28 from dj at redhat dot com 2010-08-12 18:08 ---
I built your test case with gcc and g++ without optimizations, and it worked
fine. I could only get it to fail with gcc/g++ by optimizing, but then, I
could get it to fail with MSVC by optimizing. Seems to me, gcc and MSVC
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-12 18:16 ---
Pls don't change back bug attributes all the time...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
--- Comment #29 from rogerio at rilhas dot com 2010-08-12 18:24 ---
(In reply to comment #27)
> Oh, this fun. Enjoyable, really! ;-)
Again I couldn't resist! Everytime I'm ready to go away you say something
shocking that I simply can«t resist. Its time for me to admit I have a problem!
--- Comment #30 from pinskia at gcc dot gnu dot org 2010-08-12 18:27
---
>you can't even begin to understand how to make a temporary variable an l-value.
Please look up "move constructors" and rvalue references. "move constructors"
are not standard C++ code but the C++ standard commit
--- Comment #31 from rogerio at rilhas dot com 2010-08-12 18:32 ---
(In reply to comment #28)
> I built your test case with gcc and g++ without optimizations, and it worked
> fine.
Just like my script? I noticed that I'm using a not-the-newest GCC version, and
I know that some older ver
--- Comment #32 from rogerio at rilhas dot com 2010-08-12 18:38 ---
(In reply to comment #30)
> >you can't even begin to understand how to make a temporary variable an
> >l-value.
> Please look up "move constructors" and rvalue references. "move constructors"
> are not standard C++ cod
458.sjeng compilation fails with the following config options:
( fails with gcc4.6, passes with gcc4.4, gcc4.5 not tested yet)
458.sjeng=peak=default:
ONESTEP = yes
COPTIMIZE = -fwhole-program -combine -march=amdfam10 -m64
PORTABILITY = -DSPEC_CPU_LP64
feedback = 0
Here is the message:
spe
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-12 18:47 ---
-combine is known to be broken with respect of the type checker in both 4.5 and
4.6 (though it does not ICE when you turn off checking).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45268
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-12 18:50 ---
-combine is obsolete, use LTO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45268
With gcc 4.6 on X86, 450.soplex ICE with -fprofile-generate in spxmpsread.cc:
g++ -c -o spxmpsread.o -DSPEC_CPU -DNDEBUG-fprofile-generate -O2 -m64
-DSPEC_CPU_LP64 spxmpsread.cc
spxmpsread.cc:678:1: error: Inline clone with address taken
std::basic_ostream<_CharT, _Traits>& std::endl(std:
--- Comment #33 from matz at gcc dot gnu dot org 2010-08-12 18:56 ---
> Don't talk about what you don't know, you clearly know much less about the
> old days than me.
Well, I'll grant you that you know many wondrous and astounding "facts",
indeed. Let me just answer one random sentence
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-12 18:57 ---
Probably related to PR44206.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsT
With gcc 4.6 on x86, 435.gromacs Segmentation fault with -fprofile-generate
inconstr.c:
gcc -c -DSPEC_CPU -DNDEBUG -I. -DHAVE_CONFIG_H -fprofile-generate -O2 -m64
-DSPEC_CPU_LP64 constr.c
constr.c: In function âcount_constraintsâ:
constr.c:624:5: internal compiler error: Segmentation fa
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-12 19:09 ---
It is fixed by revision 158732:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html
on trunk.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-12 19:30 ---
I believe mysql has been changed already not to rely on this.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
Hi,
the attached code fails at runtime as follows:
% ./a.out
calling cg...
cg: before g%assign
Oops in concrete_vector::my_assign : wrong type
Interchanging the indicated use statements in the main
program leads to:
% ./a.out
calling cg...
cg: before g%assign
cg: after g%assign
after cg
--- Comment #1 from anlauf at gmx dot de 2010-08-12 19:56 ---
Created an attachment (id=21471)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21471&action=view)
Demo code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
1 - 100 of 123 matches
Mail list logo
