Aaron W. LaFramboise wrote:
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
./sysdep/backtrace.h:107: error: ISO C++
On Tue, Jul 29, 2008 at 9:01 PM, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Jul 29, 2008, Richard Guenther [EMAIL PROTECTED] wrote:
why not pair the testcase with a gdb script directly?
Mostly a matter of convenience. Writing code and adding test this
here, etc, and not having to adjust a
2008/5/28 Andriy Gapon [EMAIL PROTECTED]:
on 27/05/2008 22:00 Andrew Pinski said the following:
On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon [EMAIL PROTECTED] wrote:
Thank you for the explanation! I didn't realize the difference.
OTOH, do you think that those arithmetic warnings are
2008/5/27 Andrew Pinski [EMAIL PROTECTED]:
On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon [EMAIL PROTECTED] wrote:
Thank you for the explanation! I didn't realize the difference.
OTOH, do you think that those arithmetic warnings are practical (as opposed
to being correct)?
I think so as the
Hi,
I am working with a kernel module, which was compiled using GCC
4.X, for x86_64 platform.
After dis-assembling the module object file, I see that the callq
function is always called with the next instruction of the code as the
target address(based on IP only), as the offset feild
G Shyam Sundar wrote on 30 July 2008 10:24:
What I want to understand is, how function calls work here?
Google linking.
I am not sure if this is the right list for this query. Please point
me to the right one if this is not.
This is a binutils question really.
cheers,
G Shyam Sundar wrote:
Hi,
I am working with a kernel module, which was compiled using GCC
4.X, for x86_64 platform.
After dis-assembling the module object file, I see that the callq
function is always called with the next instruction of the code as the
target address(based on IP only),
I stumbled in this while looking at how x-* host files are used. There
are two files in this configuration that must be compiled with DEC C.
One is vcrt0.o, which has about 5 lines of executable code. This makes
me think that it would be best if someone with access to the OS would
compile
I'm including Doug Rupp who is our VMS expert and is one of the people
at AdaCore maintaining the VMS port.
I stumbled in this while looking at how x-* host files are used. There are
two files in this configuration that must be compiled with DEC C.
One is vcrt0.o, which has about 5 lines
Hi Ho!
--- On Tue, 7/29/08, Neal Becker [EMAIL PROTECTED] wrote:
Paolo Carlini wrote:
... ah, ok, now I see what you meant, you meant that x is *not* finite,
still, std::isfinite(x) != 0. Still, testcase badly needed...
Paolo.
#include cmath
#include stdexcept
int main () {
Hi Ho!
--- On Tue, 7/29/08, Dennis Clarke [EMAIL PROTECTED] wrote:
hold on .. on the NEWS page I see ... okay .. how very user friendly.
Sort of the thing one would put on the project homepage I would think.
Do you mind to tell me what you saw?
I was looking for the interesting part on the
On Mon, Jul 28, 2008 at 06:39:40PM -0300, Alexandre Oliva wrote:
Here's my first cut at trying to tell how well or how bad we perform
in terms of debug info, that can be dropped into the GCC run-time test
infrastructure and used by means of #include in new tests that add
GUALCHK* annotations
Hi ho, ho!! ;)
It worked with me.
Try a recent gcc (eg, 4.3.x) and you will get the same, actually
expected, result of the original poster.
Paolo.
On Wed, Jul 30, 2008 at 3:23 PM, Eus [EMAIL PROTECTED] wrote:
Hi Ho!
--- On Tue, 7/29/08, Dennis Clarke [EMAIL PROTECTED] wrote:
hold on .. on the NEWS page I see ... okay .. how very user friendly.
Sort of the thing one would put on the project homepage I would think.
Do you mind to tell
On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog [EMAIL PROTECTED] wrote:
Raksit Ashok wrote:
There is a more optimized version for 64-bit:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
I think this looks similar to your implementation, Agner.
Yes it is
On Wed, Jul 30, 2008 at 5:57 PM, Denys Vlasenko
[EMAIL PROTECTED] wrote:
On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog [EMAIL PROTECTED] wrote:
Raksit Ashok wrote:
There is a more optimized version for 64-bit:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
Thanks Ian. I will raise this in gcc-help mailing list.
Cheers
Hari
Ian Lance Taylor wrote:
Hariharan [EMAIL PROTECTED] writes:
I found something rather strange with the unsigned comparison warnings
in GCC.
This is the wrong mailing list. The mailing list gcc@gcc.gnu.org is
for gcc
Ian Lance Taylor wrote:
Bo Yang [EMAIL PROTECTED] writes:
Could anybody give some advice on this? Thanks!
The mailing list gcc@gcc.gnu.org is for gcc developers, who mostly do
not use cygwin. Try asking on [EMAIL PROTECTED] and/or
[EMAIL PROTECTED]
For what it's worth, Bo is my intern in
Benjamin Smedberg wrote:
For what it's worth, Bo is my intern in the Google SoC and has traced this
back to being a code-generation error (missed stdcall mangling) in the mingw
backend. I will work with him to narrow the problem and reformulate the
question..
Isn't this
Andrew Haley wrote:
Aaron W. LaFramboise wrote:
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
Brian Dessent wrote:
Benjamin Smedberg wrote:
For what it's worth, Bo is my intern in the Google SoC and has traced this
back to being a code-generation error (missed stdcall mangling) in the mingw
backend. I will work with him to narrow the problem and reformulate the
question..
Isn't this
Denys Vlasenko wrote:
3164 line source file which implements memcpy().
You got to be kidding.
How much of L1 icache it blows away in the process?
I bet it performs wonderfully on microbenchmarks though.
I agree that the OpenSolaris memcpy is bigger than necessary. However,
it is necessary
2008/7/30 Aaron W. LaFramboise [EMAIL PROTECTED]:
Andrew Haley wrote:
Aaron W. LaFramboise wrote:
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code
Manuel López-Ibáñez wrote:
2008/7/30 Aaron W. LaFramboise [EMAIL PROTECTED]:
Andrew Haley wrote:
Aaron W. LaFramboise wrote:
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
On Wed, Jul 30, 2008 at 5:14 PM, Agner Fog [EMAIL PROTECTED] wrote:
Denys Vlasenko wrote:
3164 line source file which implements memcpy().
You got to be kidding.
How much of L1 icache it blows away in the process?
I bet it performs wonderfully on microbenchmarks though.
I agree that the
On Wednesday 30 July 2008 19:14, Agner Fog wrote:
I agree that the OpenSolaris memcpy is bigger than necessary. However,
it is necessary to have 16 branches for covering all possible alignments
modulo 16. This is because, unfortunately, there is no XMM shift
instruction with a variable
Snapshot gcc-4.2-20080730 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080730/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Jul 29, 2008 at 04:14:49PM +1000, Ben Elliston wrote:
Since there is no libc mailing list, I thought that the gcc list is the
place to contact the maintainers of libc. Am I on the wrong list? Or are
there no maintainers of libc?
See:
http://sources.redhat.com/glibc/
You want the
--- Comment #19 from guerby at gcc dot gnu dot org 2008-07-30 06:46 ---
Subject: Bug 5911
Author: guerby
Date: Wed Jul 30 06:45:39 2008
New Revision: 138294
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138294
Log:
gcc/ChangeLog
2008-07-29 Laurent Guerby [EMAIL PROTECTED]
On Tue, Jul 01, 2008 at 11:37:05AM +, Joseph S. Myers wrote:
On Tue, 1 Jul 2008, Michael Meissner wrote:
On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote:
On Tuesday 01 July 2008 09:24, Sajish V wrote:
Thanks for the reply, Denys.
My question was, why doesn't gcc
--- Comment #11 from manu at gcc dot gnu dot org 2008-07-30 08:31 ---
Subject: Bug 34389
Author: manu
Date: Wed Jul 30 08:30:32 2008
New Revision: 138296
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138296
Log:
2008-07-30 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #12 from manu at gcc dot gnu dot org 2008-07-30 08:36 ---
This should be mostly fixed except the following testcase in C++:
short mask1(short x)
{
short y = 0x7fff;
return x y; /* { dg-bogus conversion conversion { xfail *-*-* } 8 } */
}
This works in C, so it seems
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Hello i have code working in gcc 2.96 and porting it to gcc 4.1.1 gives me a
complete different result; please suggest what should i change in my code to
make to portable for gcc 4.1.1 specific
//code that was working in gcc 2.96
#includeiostream
#includestring
#includestdio.h
using namespace
--- Comment #15 from manu at gcc dot gnu dot org 2008-07-30 09:15 ---
Fix depends, add keyword, add alias Wundefined.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from aph at gcc dot gnu dot org 2008-07-30 09:23 ---
This patch limits recursion in tree-vrp.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 136670)
+++ tree-vrp.c (working copy)
@@ -4049,6 +4049,8 @@
--
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 #16 from manu at gcc dot gnu dot org 2008-07-30 09:26 ---
I think -Wundefined should warn for any potential undefined and unspecified
behaviour. I know they are not the same according to the standard but for a
practical point of view they both result in a behaviour that is
--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-30 10:20 ---
And
struct A
{
A ();
void *operator new (__SIZE_TYPE__, int = 0);
template typename T void operator delete (void *, T);
};
template void A::operator deleteint (void *, int);
A *p = new A;
ICEs in
--- Comment #7 from jakub at gcc dot gnu dot org 2008-07-30 10:22 ---
Any progress with this? Stage 1 will end soon...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to fail||4.4.0
--- Comment #1 from joseph at codesourcery dot com 2008-07-30 10:44 ---
Subject: Re: New: MIPS: gcc-4.3.1 still fails to compile
glibc w/ PR/35802 applied
Please don't report bugs against 4.3.1 plus a random patch; test the
current version of gcc-4_3-branch instead. This should
--- Comment #6 from michael dot a dot richmond at nasa dot gov 2008-07-30
10:49 ---
(In reply to comment #5)
The bug does not occur on snapshots released after 05/02/08
Michael, just to make sure, the reported ICE is gone for good?
(If yes, we can close this PR ...)
I have not
--
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 2008-07-30 11:57 ---
Patch has been posted 3 months ago.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2008-07-30 12:05 ---
I have not seen this bug in any version of gfortran other than the snapshot
of 05/02/08. I am willing to close this PR, along with 36139 and 36140.
Closing this PR (and the others) as WORKSFORME.
Thanks for the
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-07-30 12:07 ---
Closing as WORKSFORME - the reporter can not reproduce the problem (see
PR36157, comment #6).
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-07-30 12:07 ---
Closing as WORKSFORME - the reporter can not reproduce the problem (see
PR36157, comment #6).
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Running the testcase from PR33927 on spu-gcc 4.4.0 2008062 generates the
following code which contains a redundant creation of stack frame:
test1:
fa $3,$3,$4
stqd$sp,-48($sp)
ai $sp,$sp,-48
lnop
ai $sp,$sp,48
bi $lr
--- Comment #3 from jakub at gcc dot gnu dot org 2008-07-30 12:39 ---
I think there are many bugs that are only reported when a template is
instantiated, and this is just one of them.
If you add
Bint b;
to the testcase, it will be rejected. IMHO this isn't a bug.
--
jakub at gcc
--- Comment #8 from jakub at gcc dot gnu dot org 2008-07-30 12:40 ---
I agree there is no need to fix this on the older branches.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2008-07-30 13:00
---
Note that changes to gnattools/ are to be described in gnattools/ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
--- Comment #14 from dodji at gcc dot gnu dot org 2008-07-30 13:09 ---
Subject: Bug 36767
Author: dodji
Date: Wed Jul 30 13:07:50 2008
New Revision: 138308
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138308
Log:
2008-07-30 Dodji Seketeli [EMAIL PROTECTED]
PR
--- Comment #21 from bonzini at gnu dot org 2008-07-30 13:10 ---
Yes, I already moved the relevant entry to gnattools/ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
--- Comment #6 from bonzini at gnu dot org 2008-07-30 13:12 ---
reopened just because it is not a dup of PR5911...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2008-07-30 13:12 ---
... and closed because it was fixed by the introduction of libaad
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #15 from dodji at gcc dot gnu dot org 2008-07-30 13:19 ---
Subject: Bug 36767
Author: dodji
Date: Wed Jul 30 13:18:31 2008
New Revision: 138309
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138309
Log:
2008-07-30 Dodji Seketeli [EMAIL PROTECTED]
PR
--
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
ICE when compiling legal(at least compiles with 4.1.2) code
I will attach the preprocessed compilation unit.
--
Summary: ICE when compiling legal(at least compiles with 4.1.2)
code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
--- Comment #1 from r0bertz at gentoo dot org 2008-07-30 13:49 ---
configured with:
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20080718/work/gcc-4.4-20080718/configure
--prefix=/usr
--bindir=/usr/mipsel-unknown-linux-gnu/gcc-bin/4.4.0-alpha20080718
--- Comment #2 from r0bertz at gentoo dot org 2008-07-30 13:52 ---
Created an attachment (id=15977)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15977action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36973
--- Comment #3 from r0bertz at gentoo dot org 2008-07-30 13:53 ---
mipsel-unknown-linux-gnu-gcc -c -O2 -march=loongson2f -mabi=32 -pipe -W -Wall
-DHAVE_CONFIG_H -I. -I. -I../include -I../include -D_REENTRANT
-DPATH_SANE_CONFIG_DIR=/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/share
--- Comment #16 from jakub at gcc dot gnu dot org 2008-07-30 13:53 ---
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from r0bertz at gentoo dot org 2008-07-30 13:55 ---
the exact error message is:
hp3900.c: In function 'fitcalibrate_get':
hp3900.c:61: internal compiler error: Segmentation fault
sorry for sending so many times.
this is my first time to file gcc bugs.
i will send all
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-30 14:46 ---
well...
(gdb) call debug_tree (t)
ssa_name 0x775338c0 nothrow var var_decl 0x7752faa0
prephitmp.162def_stmt
version 447 in-free-list
we release the SSA_NAME with remove_phi_node (psi, true); before
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30774
--- Comment #5 from froydnj at gcc dot gnu dot org 2008-07-30 15:32 ---
Subject: Bug 35866
Author: froydnj
Date: Wed Jul 30 15:30:59 2008
New Revision: 138316
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138316
Log:
PR target/35866
* config/rs6000/rs6000.h
--- Comment #10 from dvilleneuve at kronos dot com 2008-07-30 15:39 ---
An updated patch for gcc 4.3 is available in the following message:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00653.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
Gcc 4.4 revision 138310 failed to bootstrap on Linux/ia64:
./../../src/libgcc/../gcc/libgcc2.c: In function '__addvsi3':
../../../src/libgcc/../gcc/libgcc2.c:104: internal compiler error: in
call_from_call_insn, at final.c:1760
Please submit a full bug report,
with preprocessed source if
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-30 15:45 ---
Subject: Bug 36967
Author: rguenth
Date: Wed Jul 30 15:43:42 2008
New Revision: 138318
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138318
Log:
2008-07-30 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-30 16:04 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-30 16:05 ---
Fixed by the tuples merge.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-30 16:24 ---
[EMAIL PROTECTED] libgcc]$ cat foo.i
extern void abort (void);
typedef int SItype __attribute__ ((mode (SI)));
typedef unsigned int USItype __attribute__ ((mode (SI)));
SItype
__addvsi3 (SItype a, SItype b)
{
-fpreprocessed
foo.i -quiet -dumpbase foo.i -auxbase foo -O -version -o foo.s
GNU C (GCC) version 4.4.0 20080730 (experimental) [trunk revision 138310]
(ia64-unknown-linux-gnu)
compiled by GNU C version 4.1.2 20071124 (Red Hat 4.1.2-42), GMP
version 4.2.2, MPFR version 2.3.1.
GGC heuristics
--- Comment #22 from laurent at guerby dot net 2008-07-30 16:32 ---
Sorry about the misplaced ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
Hi all,
gcc-4.2.2 seems to generating wrong/misaligned code for movapd.
I have used the same test case mentione here (for almost the similar bug)
http://gcc.gnu.org/bugzilla/attachment.cgi?id=6012
The relavent information about the version and the files are as follows:
The version of gcc:
gcc
--- Comment #3 from espindola at google dot com 2008-07-30 16:51 ---
Created an attachment (id=15978)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15978action=view)
proposed fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36974
--- Comment #11 from tromey at gcc dot gnu dot org 2008-07-30 17:44 ---
Please ping that patch on the gcc-patches list.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
--- Comment #6 from burnus at gcc dot gnu dot org 2008-07-30 18:06 ---
For an initial, incomplete patch see:
http://gcc.gnu.org/ml/fortran/2008-07/msg00248.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
--- Comment #5 from schwab at gcc dot gnu dot org 2008-07-30 18:24 ---
Subject: Bug 36929
Author: schwab
Date: Wed Jul 30 18:22:50 2008
New Revision: 138333
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138333
Log:
PR rtl-optimization/36929
* dse.c (replace_inc_dec): Use
--- Comment #6 from schwab at suse dot de 2008-07-30 18:24 ---
Fixed in 4.3 branch and trunk.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #7 from schwab at gcc dot gnu dot org 2008-07-30 18:24 ---
Subject: Bug 36929
Author: schwab
Date: Wed Jul 30 18:23:14 2008
New Revision: 138334
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138334
Log:
PR rtl-optimization/36929
* dse.c (replace_inc_dec): Use
--- Comment #7 from gcc-gnu-org at the-tilghman dot com 2008-07-30 18:38
---
Fixed by adding noclobber to the assembly of the code in question.
--
gcc-gnu-org at the-tilghman dot com changed:
What|Removed |Added
overload-address.cc: In function void g():
overload-address.cc:6: error: address of overloaded function with no contextual
type information
while compiling this:
void f(int);
void f(double);
void g()
{
(f)(1.0); // well-formed, see 13.3.1.1p3 over.match.call
}
--
Summary:
Some newly added stack alignment tests failed on Linux/ia32:
FAIL: g++.dg/torture/stackalign/unwind-2.C -O1 execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C -O3 -fomit-frame-pointer execution
test
FAIL:
In expand_stack_alignment, we decide we need to relign stack to support
big outgoing stack boundary. Reload will make frame pointer available
for stack alignment by eliminating it to stack pointer. After reload,
we realize that we don't need to relign stack after all, for example,
callee doesn't
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-30 21:27 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02351.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from jwakely dot gcc at gmail dot com 2008-07-30 21:27
---
Created an attachment (id=15979)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15979action=view)
unique_ptr and rvalue-reference updates from WP
I'm going to be offline until next week so here's what I have
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-30 21:49
---
Many thanks Jonathan! By the time you will be back online, my comments will be
ready and in any case will be able to commit the changes! Thanks again, Paolo.
--
--- Comment #13 from hjl dot tools at gmail dot com 2008-07-30 21:53
---
Do you still see it after revision 38335? If you really want, you
can check MAX_SUPPORTED_STACK_ALIGNMENT, but not PREFERRED_STACK_BOUNDARY.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
--- Comment #14 from hjl dot tools at gmail dot com 2008-07-30 21:58
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02378.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from espindola at gcc dot gnu dot org 2008-07-30 23:24
---
Subject: Bug 36974
Author: espindola
Date: Wed Jul 30 23:23:33 2008
New Revision: 138347
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138347
Log:
2008-07-30 Rafael Avila de Espindola [EMAIL PROTECTED]
The following C testcase was reduced from a C++ benchmark:
unsigned short status;
void foo (const _Bool flag)
{
if (status == 2 || status == 7)
{
while (status != 2 (status != 7 || !flag))
{
}
}
}
After the merge of the tuples branch into
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-07-30 23:39
---
Recategorizing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-30 23:53 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-07-30 23:56
---
Subject: Bug 36554
Author: ebotcazou
Date: Wed Jul 30 23:54:56 2008
New Revision: 138348
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138348
Log:
PR ada/36554
* dwarf2out.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-30 23:59 ---
(gdb) p debug_generic_expr (lhs)
(_Bool) flag_7(D)
In tree_may_unswitch_on, we have:
126 cond = fold_build2 (gimple_cond_code (stmt), boolean_type_node,
127 gimple_cond_lhs (stmt),
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-07-30 23:59
---
Sort of.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from hjl dot tools at gmail dot com 2008-07-31 01:04
---
(In reply to comment #0)
Running the program below compiled with -mpreferred-stack-boundary=2
gets a segmentation fault because the variable tmp
is not properly aligned on a 16-byte boundary (required for
1 - 100 of 110 matches
Mail list logo
