Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a (c 0x1f);
}
The macro was defined as:
+/* Implement TARGET_SHIFT_TRUNCATION_MASK. */
+static unsigned HOST_WIDE_INT
On 12/07/10 14:25, Andrew Stubbs wrote:
This means that we need to choose a name for it. Obviously, it's better
if it's an official name, so I want to discuss it here. I'm aware that
there is some bikeshedding to do here, but it's better it gets done
before anybody gets stuck with something
On 15 July 2010 10:54, Gerald Pfeifer wrote:
How shall we address this for real? Is it really worthwhile to manually
generate those .html.gz files for onlinedocs/libstdc++ or could we simply
omit that step? Not sure it's really worth the hassles?
I have no idea why we gzip them, it
On 07/15/2010 09:57 AM, Uros Bizjak wrote:
Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a (c 0x1f);
}
The macro was defined as:
+/* Implement
On Thu, Jul 15, 2010 at 2:16 PM, Paolo Bonzini bonz...@gnu.org wrote:
On 07/15/2010 09:57 AM, Uros Bizjak wrote:
Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a (c
Hello,
I started to look at VTA recently and check whether our port passes
the -fcompare-debug test. Our port contains some extra passes for
our VLIW target.
What I have trouble is with our modulo scheduling pass (based on
IMS algorithm). I noticed that debug_insns are built into DDG,
and has
Snapshot gcc-4.5-20100715 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100715/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This is the code.
--
#define PointerA struct a *
void f( PointerA );
typedef struct a * PA;
struct a { int x; };
void f( PA a )
{
}
-
This is the output
warning: 'struct a' declared inside parameter list
warning: its scope is
Testing the mingw64-i686* packages found at
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW (Cygwin cross
compiler, see[*]), I have obtained an ICE:
$ cat ICE_test.cpp
void foo(char const* upattern, int color)
{
static short bitmap_data[8];
for (int i = 0; i 8; i++)
{
On 16/07/2010 00:59, J Decker wrote:
--
#define PointerA struct a *
void f( PointerA );
typedef struct a * PA;
struct a { int x; };
void f( PA a )
{
}
-
This is the output
warning: 'struct a' declared inside
On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
On 16/07/2010 00:59, J Decker wrote:
--
#define PointerA struct a *
void f( PointerA );
typedef struct a * PA;
struct a { int x; };
void f( PA a )
{
}
On 16/07/2010 01:21, J Decker wrote:
Now it's happy, why can't it just define 'struct a' as an appropriate
name as it used to, the strucutre still isn't defined.
That's just the way that C works, I'm afraid.
(okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc
before
Oh not so bad then, I can just add at the beginning...
typedef struct a *NeverUsedDefinition;
and now it's happy? And that makes good coding how? If I never
actually use 'NeverUsedDefinition'? Actually this 'feature' now
causes useless and unused declartions to be created.
On Thu, Jul 15,
On Fri, 2010-07-16 at 02:06 +0200, Angelo Graziosi wrote:
Testing the mingw64-i686* packages found at
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW (Cygwin cross
compiler, see[*]), I have obtained an ICE:
$ cat ICE_test.cpp
void foo(char const* upattern, int color)
{
static
On 16/07/2010 01:31, J Decker wrote:
Oh not so bad then, I can just add at the beginning...
typedef struct a *NeverUsedDefinition;
and now it's happy? And that makes good coding how?
No, that would be bad coding. Just forward-declare the tag:
struct a;
before you try and use it in a
On Thu, Jul 15, 2010 at 5:31 PM, J Decker d3c...@gmail.com wrote:
Oh not so bad then, I can just add at the beginning...
typedef struct a *NeverUsedDefinition;
and now it's happy? And that makes good coding how? If I never
actually use 'NeverUsedDefinition'? Actually this 'feature' now
On Thu, Jul 15, 2010 at 6:08 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
On 16/07/2010 01:31, J Decker wrote:
Oh not so bad then, I can just add at the beginning...
typedef struct a *NeverUsedDefinition;
and now it's happy? And that makes good coding how?
No, that would be bad
--- Comment #7 from roy dot 1rosen at gmail dot com 2010-07-15 06:52
---
Looks good now.
Thanks for the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44479
--- Comment #12 from burnus at gcc dot gnu dot org 2010-07-15 07:05 ---
Can you send the patch also to fortran@ and gcc-patc...@?
And can you fix the changelog by adding a line for io/transfer.c? It looks as
if you only changed the indenting, but I might be wrong.
The patch itself
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-15 07:17 ---
Fixed then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-15 07:53 ---
Subject: Bug 40206
Author: jakub
Date: Thu Jul 15 07:52:51 2010
New Revision: 162209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162209
Log:
PR fortran/40206
* trans-stmt.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 08:00 ---
Works on x86_64 with -m32. Does the testcase work with GCC 4.4? Does it work
with the 4.5.0 release?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from graham dot gower at gmail dot com 2010-07-15 08:03
---
Works with 4.4.4. I can check 4.5 release tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44944
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-15 08:06 ---
Confirmed.
--
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.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44941
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-15 08:21 ---
Confirmed.
(gdb) call debug_gimple_stmt (stmt)
.MEM_12 = PHI .MEM_13(D)(2), (3)
we miss a PHI arg here after splitting the function.
func_4 (int p_5, unsigned char p_6, unsigned char p_7)
{
bb 2:
if (p_6_3(D)
At revision 162192, I get with -m32:
FAIL: gfortran.dg/char_array_structure_constructor.f90 -O3
-fomit-frame-pointer execution test
The failure is a Bus error with -O2 and -O3, and requires
-fomit-frame-pointer. Also the failure goes away when Revision 162148 was OK
and the test passes on
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-15 08:37 ---
Works with my pending set of patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945
This might be related to PR44941.
Command line:
$ gcc -O2 testcase.c
Output:
$ gcc -O2 testcase.c
testcase.c: In function 'foo':
testcase.c:22:1: internal compiler error: in get_constraint_for_component_ref,
at tree-ssa-structalias.c:3184
Please submit a full bug report,
with preprocessed source
--- Comment #1 from zsojka at seznam dot cz 2010-07-15 09:00 ---
Created an attachment (id=21208)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21208action=view)
reduced testcase (from wget sources)
Command line:
$ gcc -O2 pr44946.c
--
Hi all,
I have an interesting problem with gcc optimizing away an automatic variable
in a function which uses setjmp/longjmp in a macro-based exception processing
framework. Here's some example code (just to illustrate the problem, I haven't
tested this code):
#include stdlib.h
#include stdio.h
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I edited the contents of the precompiler output to make it more readable
and messed up the auto variable name. Please use this code:
#include stdlib.h
#include stdio.h
#include setjmp.h
#define EXC_TRY 1
#define
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-15 09:18 ---
You need to mark auto variables that are life across setjmp/longjmp calls as
volatile.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
On Jul 15, 2010, at 2:15 AM, cm1 at mumac dot de gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I edited the contents of the precompiler output to make it
more readable
and messed up the auto variable name. Please use this
--- Comment #3 from pinskia at gmail dot com 2010-07-15 09:19 ---
Subject: Re: Optimizer doesn't see setjmp()
On Jul 15, 2010, at 2:15 AM, cm1 at mumac dot de gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I
Hi everybody!
Here is my problem : I wrote a c++ program on Linux which uses the pthread
library to handle several requests of several clients. Each request executes
an algo in which some parts, some loops, are parallelized with openmp (on 2
processors). I compile my program with gcc 4.3.
With
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-15 09:21 ---
Confirmed. It's mem-ref related.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hubicka at ucw dot cz 2010-07-15 09:37 ---
Subject: Re: [4.6 Regression] IPA-split
causes crash due to null pointer deref
(gdb) call debug_gimple_stmt (stmt)
.MEM_12 = PHI .MEM_13(D)(2), (3)
Hmm, I make no attempts to update alias info. Why return has
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-15 09:49 ---
Seems ix86_function_arg_advance ignores padding for 8 byte aligned arguments
when updating cum-words.
With:
#include stdarg.h
long double
test (int a, int b, int c, int d, int e, int f, int g, int g2, int g3, long
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 09:58 ---
It doesn't. It's a PHI node. So I suppose there was a CFG confluence
point here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44937
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-15 10:00 ---
CDDCE removes the single store in the loop but doesn't remove the virtual
PHI nodes. But you still have to deal with them I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44937
The gcc-bugs mailing list is for emails automatically generated by our
bug database, to report a bug please follow the instructions at
http://gcc.gnu.org/bugs/
However, your email doesn't seem to be a bug report and you don't give
enough information for a useful bug report, you haven't said what
--- Comment #4 from cm1 at mumac dot de 2010-07-15 10:14 ---
Thanks for the quick explanation and sorry for joining the club of submit
first, read the specs later folks -- I actually thought I knew them ;)
It makes of course sense to use volatile in the presence of setjmp/longjmp but
Ok, thanks for your answer.
I will try to simplify my code (several header and source files) to keep
only the part which produces the error, and I will post on the good forum
with more precisions on the problem.
Thanks.
--
View this message in context:
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 11:17 ---
Subject: Bug 44946
Author: rguenth
Date: Thu Jul 15 11:17:37 2010
New Revision: 162216
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162216
Log:
2010-07-15 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from hubicka at ucw dot cz 2010-07-15 11:31 ---
Subject: Re: [4.6 Regression] IPA-split
causes crash due to null pointer deref
CDDCE removes the single store in the loop but doesn't remove the virtual
PHI nodes. But you still have to deal with them I guess.
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-15 11:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-15 12:03 ---
Created an attachment (id=21209)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21209action=view)
gcc46-pr44942.patch
Untested fix. Grep tells me that cum-words is only ever used for x86-64
va_start expansion
With two sources:
struct A { long b[8] __attribute__((aligned (32))); };
void foo (long double, struct A);
int
main (void)
{
struct A a = { { 0, 1, 2, 3, 4, 5, 6, 7 } };
foo (8.0L, a);
return 0;
}
and:
struct A { long b[8] __attribute__((aligned (32))); };
void
foo (long double x, struct A
--- Comment #4 from domob at gcc dot gnu dot org 2010-07-15 12:24 ---
Subject: Bug 44709
Author: domob
Date: Thu Jul 15 12:23:47 2010
New Revision: 162219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162219
Log:
2010-07-15 Daniel Kraft d...@domob.eu
PR fortran/44709
--- Comment #5 from domob at gcc dot gnu dot org 2010-07-15 12:31 ---
Fixed the clean-up issues. Still remaining is the rejects-valid (2b) of
Tobias' original comment. I'll keep on with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44709
--- Comment #7 from uweigand at gcc dot gnu dot org 2010-07-15 12:38
---
Subject: Bug 44877
Author: uweigand
Date: Thu Jul 15 12:37:03 2010
New Revision: 162220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162220
Log:
PR target/44877
* config/spu/spu.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-15 13:11 ---
How should we align
struct A { long b[8] __attribute__((aligned (32))); };
when it is passed on stack?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-15 13:15 ---
If we want to be ABI compatible, I'm afraid it needs to be 16 byte aligned
only.
We don't align aligned(64) structs to 64 bytes either, even with -mavx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-07-15
13:19 ---
At -m32 on x86_64-apple-darwin10, the test cases which fail due to symbols
being optimized away include...
FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link,
-O2 -fwhopr
FAIL:
--- Comment #3 from hjl dot tools at gmail dot com 2010-07-15 13:26 ---
Caller and call expander try to honor type alignment.
See PR 35771 and PR 35767. I think we should replace
BIGGEST_ALIGNMENT with MAX_STACK_ALIGNMENT.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-15 13:33 ---
(In reply to comment #2)
If we want to be ABI compatible, I'm afraid it needs to be 16 byte aligned
only.
We don't align aligned(64) structs to 64 bytes either, even with -mavx.
That is because we couldn't
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-15 13:36 ---
Subject: Bug 44936
Author: janus
Date: Thu Jul 15 13:36:28 2010
New Revision: 162221
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162221
Log:
2010-07-15 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-15 13:42 ---
We have aligned double to 4 byte when passing on stack
in 32bit. I guess it is OK to use a smaller alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #4 from janus at gcc dot gnu dot org 2010-07-15 13:42 ---
Fixed with r162221. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2010-07-15 13:56 ---
When we pass 32byte aligned type on stack with 16byte
alignment, do we mark it as 16byte aligned or 32byte
aligned?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #7 from hjl dot tools at gmail dot com 2010-07-15 14:10 ---
For 32bit, we should align it to 4 byte.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
This is about both C and C++.
gcc warns about a construction like i2==0, and this helped us find bugs. But
we noticed, in the same code, occurrences of: i=2==0. This code suffers from
the same problem, but gcc doesn't warn about it. Would it be a good idea to
extend the warning to this case?
--
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-15 14:38 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-15 14:37 ---
0x000adddc in __gfortran_compare_string (len1=4, s1=0x0, len2=4, s2=0x1f40
s1 should not be NULL but the value of c%a. The question is why does this
fail now. Recently added were: PURE and the fn spec of ..R.R.
j...@evans:/abuild/jh/build-mozilla-debug/js/src/shell
/abuild/jh/trunk-install/bin/g++ -fwhopr=24 -fuse-linker-plugin -fpermissive
-o js.o -c -I../../../dist/system_wrappers_js -include
/abuild/jh/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API
-DOSTYPE=\Linux2.6.32.12-0\
--- Comment #9 from jakub at gcc dot gnu dot org 2010-07-15 15:09 ---
Should be fixed now for 4.6+.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
j...@evans:/abuild/jh/build-mozilla-debug/toolkit/crashreporter/google-breakpad/src/common/dwarf
/abuild/jh/trunk-install/bin/g++ -fwhopr=24 -fuse-linker-plugin -fpermissive
-funsigned-char host_bytereader.ii -c
--- Comment #3 from zsojka at seznam dot cz 2010-07-15 15:16 ---
Created an attachment (id=21210)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21210action=view)
different testcase, reduced
$ gcc -O2 -finline-functions testcase.c
testcase.c:37:1: error: caller edge frequency 1142
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-15 15:17 ---
Created an attachment (id=21211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21211action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44951
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-15 15:22 ---
Created an attachment (id=21212)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21212action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44950
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-15 15:23 ---
Created an attachment (id=21213)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21213action=view)
dump with -m32 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
--- Comment #3 from dominiq at lps dot ens dot fr 2010-07-15 15:24 ---
Created an attachment (id=21214)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21214action=view)
dump with -m64 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-15 15:27 ---
Created an attachment (id=21215)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21215action=view)
dump with -m64 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 15:47 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
#include iostream
evans:/abuild/jh/trunk-install/bin/:[0]# ./g++ -O2 g.C -S
evans:/abuild/jh/trunk-install/bin/:[0]# more g.s
.file g.C
.text
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-15 16:02 ---
(In reply to comment #3)
Caller and call expander try to honor type alignment.
See PR 35771 and PR 35767. I think we should replace
BIGGEST_ALIGNMENT with MAX_STACK_ALIGNMENT.
The call expander should not look
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-15 16:02 ---
According to gcc-testresults this seems to affect only Darwin, cf.
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg01432.html
The optimized dumps also seem to be OK (or at there is no obvious difference).
In the
This is expected and iirc required by the c++ standard too.
On Jul 15, 2010, at 8:51 AM, hubicka at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
--- Comment #1 from pinskia at gmail dot com 2010-07-15 16:02 ---
Subject: Re: New: #include iostream.h imply global constructor.
This is expected and iirc required by the c++ standard too.
On Jul 15, 2010, at 8:51 AM, hubicka at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-15 16:03 ---
Why's this not in libstdc++.so .init?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2010-07-15 16:05 ---
How about this patch?
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4fd2aab..65e13a3 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -6594,8 +6594,8 @@
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-07-15 16:12 ---
... and are we required to emit the constructor even if we know var is not
used?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- Comment #10 from hjl dot tools at gmail dot com 2010-07-15 16:20
---
Created an attachment (id=21216)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21216action=view)
A patch
I am testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #6 from dominiq at lps dot ens dot fr 2010-07-15 16:25 ---
a) _gfortran_compare_string is now PURE,
http://gcc.gnu.org/viewcvs?view=revisionrevision=162160
The test passes with the following patch:
--- ../_clean/gcc/fortran/trans-decl.c 2010-07-15 18:05:19.0
--- Comment #11 from jakub at gcc dot gnu dot org 2010-07-15 16:28 ---
That is going to break the ABI a lot. You'd e.g. change long double passing
for -m64.
What you IMHO want is to do what the code currently does, and if the alignment
after that is 32 bytes, use a predicate similar to
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-15 16:30 ---
(In reply to comment #2)
Why's this not in libstdc++.so .init?
because this will not work if libstdc++ is a static library.
Take:
#include iostream
namespace {
struct g
{
g(){ std::cout t; }
};
g one;
}
---
gfortran.dg/char4_iunit_1.f03 fails on powerpc-apple-darwin9 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg01445.html ).
It looks like an endianess issue.
--
Summary: FAIL: gfortran.dg/char4_iunit_1.f03 * execution test
Product: gcc
Version: 4.6.0
--- Comment #5 from redi at gcc dot gnu dot org 2010-07-15 16:38 ---
This is why you should only include iostream if you want actually want
std::cin, std::cout or std::cerr (or the wide character equivalents.)
Otherwise you should only include one or more of iosfwd, istream and
ostream,
--- Comment #12 from hjl dot tools at gmail dot com 2010-07-15 16:41
---
Created an attachment (id=21217)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21217action=view)
A new patch
How about this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #6 from redi at gcc dot gnu dot org 2010-07-15 16:45 ---
and please ... it's 2010, iostream not iostream.h ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- Comment #13 from hjl dot tools at gmail dot com 2010-07-15 16:47
---
struct A {
long b[8] __attribute__((aligned (32)));
__m128i x;
};
What alignment should we use to pass it on stack?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
I believe this is related to Bug #43493
I cannot catch exceptions if a variable (non-static) is use for the message...
Using the following program:
#include cstdlib
#include iostream
#include sstream
#include stdexcept
#include string
using namespace std;
void generateException(int
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-07-15 16:53 ---
Hehe, I am really not C++ guy even in 2010, but I have impression that people
are including iostream without really thinking about consequences here.
Well, so what we can do about the startup times then? I will
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-15 16:53 ---
(In reply to comment #0)
However, when I compile with gcc 4.3 or 4.4 installed with macports 1.9.1 I
get:
How is that gcc configured?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44954
--- Comment #2 from mwglass at sandia dot gov 2010-07-15 16:56 ---
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.4.4/configure --prefix=/opt/local
--build=x86_64-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,java,fortran
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-07-15 16:57 ---
IIRC this is a bug in Apple's unwinder.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44954
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-07-15 16:57
---
*** Bug 44954 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-15 16:57 ---
*** This bug has been marked as a duplicate of 42159 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 154 matches
Mail list logo
