--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-07-16 06:44
---
I am attempting a build on a PPC machine to see if I can fix this. I suspect I
am missing a few casts in the right places.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-07-13 02:08
---
Subject: Bug 37077
Author: jvdelisle
Date: Tue Jul 13 02:07:48 2010
New Revision: 162122
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162122
Log:
2010-07-12 Jerry DeLisle
PR fortran/37077
--- Comment #21 from pault at gcc dot gnu dot org 2010-07-16 04:49 ---
I tried to fix 4.3 but failed to find an easy way of overcoming problems with
4.3. Since this bug has been present for 10 years without being reported, I
feel quite relaxed about leaving 4.3 as it is.
Fixed on 4.4-4
--- Comment #5 from pault at gcc dot gnu dot org 2010-07-16 04:39 ---
PR closed. Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-16 04:28 ---
(In reply to comment #6)
> Please don't keep reopening this bug.
> The symbols are weak undefs because libgfortran doesn't require (and shouldn't
> require) libpthread, it is thread-safe only when libpthread is linked
--- Comment #8 from victor dot pasko at gmail dot com 2010-07-16 03:55
---
You know, libgfortran works incorrectly with weak symbols from pthread :(
In case of static library it needs to call these functions only if its value is
not NULL.
So, the follwing is to be:
if(pthread_cancel
--- Comment #5 from graham dot gower at gmail dot com 2010-07-16 02:10
---
4.5 release has the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44944
--- Comment #4 from bernds at gcc dot gnu dot org 2010-07-16 02:09 ---
Subject: Bug 42235
Author: bernds
Date: Fri Jul 16 02:09:03 2010
New Revision: 162240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162240
Log:
PR target/42235
* function.c (record_hard_reg_s
--- Comment #4 from danglin at gcc dot gnu dot org 2010-07-16 01:01 ---
Also in hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from hjl dot tools at gmail dot com 2010-07-15 23:26
---
Created an attachment (id=21220)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21220&action=view)
Another patch
This patch always aligns struct properly in 64bit
and aligns struct properly in 32bit if its al
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-07-15 23:13
---
(In reply to comment #10)
> Pinski, got test case?
No I don't have one. At this point I was filing bugs about the FIXME's inside
the compiler itself. This comment is still there. If this is now fixable with
MEM
--- Comment #10 from steven at gcc dot gnu dot org 2010-07-15 23:09 ---
Pinski, got test case?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #9 from steven at gcc dot gnu dot org 2010-07-15 23:08 ---
If the quoted comment in this bug's comment #0 is true, then this bug should be
fixable with MEM_REF.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-07-15 23:06
---
Martin just removed the language hook. The comment in the source about fold is
invalid now as we have tuples. Though it looks like there a new comment about
"fold_stmt_inplace".
--
pinskia at gcc dot gnu dot o
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-15 23:05 ---
Fixed in the previous decade.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from LpSolit at netscape dot net 2010-07-15 23:04 ---
For those who are interested, I'm on vacation till mid-August, meaning that I
have some free time to help upgrading GCC Bugzilla to 3.6.1.
As it's not acceptable to play with a production installation, we would need a
--- Comment #9 from steven at gcc dot gnu dot org 2010-07-15 23:02 ---
Wasn't this done (at least partially) by Martin?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-15 22:56 ---
Fixed by Nathan Froyd's patches.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-15 22:50 ---
Would be quite useful, though, for languages that do not have/allow pointer
arithmetic.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from hjl dot tools at gmail dot com 2010-07-15 22:47
---
I think we should always properly align the struct.
Otherwise, we have to deal with:
struct A { long b[8] __attribute__((aligned (32))); };
extern bar (struct A *p);
void
foo (struct A y)
{
bar (&y);
...
}
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-15 22:43 ---
I would be surprised if this is not fixed now. Can someone with Java-fu check?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from hjl dot tools at gmail dot com 2010-07-15 22:29
---
(In reply to comment #4)
> (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 -mav
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-15 21:57 ---
Spin-off: PR44960
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
Spin-off from PR43179:
type t
integer :: a
end type t
type(t) :: foo
! external :: foo ! "Syntax error in PRINT"
print *, foo(1)%a
end
foo is used as an array although no declared as one; gfortran takes it as an
external function, although one can not access components of returned type
--- Comment #4 from jkrahn at nc dot rr dot com 2010-07-15 21:49 ---
I noticed that Fedora now include symlinks for /dev/stdin, /dev/stdout,
/dev/stderr. It would be reasonable to use those path names if there is an
interest in avoiding blank names. This convention may not hold on all
pl
X-Bugzilla-Reason: CC
The problem was first noticed with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894#c4 with svn-r152154 .
Now that 4.5.0 is released, here is the build failure - it looks the same as in
the url above, and earlier than bug 40894 so this I guess qualifies as a new
bug.
mak
--- Comment #3 from jkrahn at nc dot rr dot com 2010-07-15 21:39 ---
Intel Fortran currently returns the actual device name (e.g. "/dev/pts/3") but
also uses "stdin" if the input is from a pipe. I sent a similar low-priority
bug report to Intel, and they tentatively agree that the "stdin
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-07-15 21:39 ---
(From update of attachment 20021)
Obsolete duplicate.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-07-15 21:37
---
> > (In reply to comment #13)
> >> I'm leaving this assigned to Janus because, as OOP master, he knows best
> >> the
> >> place(s) where the change(s) have to be applied, for better cleanness,
> >> bullet-proof-ne
--- Comment #5 from mikpe at it dot uu dot se 2010-07-15 21:30 ---
Created an attachment (id=21219)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21219&action=view)
updated long long to double conversion test
I've updated the test case to try conversions of a larger range of value
--- Comment #3 from htl10 at users dot sourceforge dot net 2010-07-15
21:29 ---
Adding a few releases I have tried (4.3.4, 4.3.5, 4.4.4 and 4.5.0 all failed),
and 4.4.1 worked.
I can try 4.4.2 and 4.4.3 as well if somebody insists.
--
htl10 at users dot sourceforge dot net changed:
--- Comment #7 from jason at gcc dot gnu dot org 2010-07-15 20:45 ---
Subject: Bug 44909
Author: jason
Date: Thu Jul 15 20:45:35 2010
New Revision: 162233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162233
Log:
PR c++/44909
* call.c (add_function_candidate): I
Gcc generates poor codes for this:
[...@gnu-6 tmp]$ cat x.i
typedef unsigned int fpu_control_t __attribute__ ((__mode__ (__HI__)));
extern fpu_control_t __fpu_control;
struct rtld_global_ro
{
fpu_control_t _dl_fpu_control;
};
extern const struct rtld_global_ro _rtld_global_ro;
extern void __setf
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-15 20:20 ---
Ah, so -fdump-tree-optimized dump doesn't reveal the problem, but
-fdump-tree-optimized-all actually does. The problem is that each routine -
char_array_structure_constructor and alloc, use different decls for the sam
--- Comment #3 from dominiq at lps dot ens dot fr 2010-07-15 19:35 ---
If I print the different strings, I get:
abcdefg
? 12345
78932 123456 abc
??
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-15 19:21 ---
>From http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip , I think the
failures on regress come after a clean bootstrap as well as my build for
r162194.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44953
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-07-15 19:08
---
You do have to make sure you do a clean build. I noticed some dependency
issues while developing the patch. I am not sure it was io.h or
write_float.def. Regardless, check that first and I will touch base with
--- Comment #14 from hjl dot tools at gmail dot com 2010-07-15 19:07
---
(In reply to comment #13)
> struct A {
> long b[8] __attribute__((aligned (32)));
> __m128i x;
> };
>
> What alignment should we use to pass it on stack?
>
I think when such a struct is passed on stack, the
--- Comment #7 from dominiq at lps dot ens dot fr 2010-07-15 18:55 ---
Created an attachment (id=21218)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21218&action=view)
assembly generated with -S -m32 -O2 -fomit-frame-pointer -fverbose-asm
The original file has been modified to h
--- Comment #9 from paolo dot carlini at oracle dot com 2010-07-15 18:26
---
Let's say we remove that horrible .h from the Summary, since, to be fair,
didn't exist in g.C in the first place ;)
That said, I agree with Jon, by and large, with the following minor additional
observations:
--- Comment #8 from redi at gcc dot gnu dot org 2010-07-15 17:49 ---
(In reply to comment #7)
> 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.
Yes, and in many cases that's the simpl
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-15 17:48 ---
(In reply to comment #0)
> When compiling a generic procedure, the generic name is not entered in the
> symbol table, which then causes subsequent 'use' statements to fail.
>
> Example:
>
> in m_die.F90 we declare:
>
--- Comment #2 from rakdver at kam dot mff dot cuni dot cz 2010-07-15
17:44 ---
Subject: Re: over-prefetched for arrays of
complex number
> This is a piece of code that shows the two prefetches for b.
>
> mulss %xmm4, %xmm5
> addq$8, %rdx
> prefe
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-15 17:39 ---
fixed in 4.4.3 as well
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44956
When compiling a generic procedure, the generic name is not entered in the
symbol table, which then causes subsequent 'use' statements to fail.
Example:
in m_die.F90 we declare:
module m_die
use m_mpif90, only : MP_perr
implicit none
private ! except
public :: die
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-15 17:21 ---
This has been at least fixed in 4.5.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44956
--- Comment #1 from changpeng dot fang at amd dot com 2010-07-15 17:20
---
This is a piece of code that shows the two prefetches for b.
mulss %xmm4, %xmm5
addq$8, %rdx
prefetcht0 96(%r11)
prefetcht0 100(%r11)
subss %xmm2, %xmm1
When using templates, A::f should not be reachable from main() because it
is protected.
The correct behavior is observed in the template-less version: the compiler
detects an encapsulation error.
% cat foo.cpp
#if NO_TEMPLATES == 1
class A { protected: int f() { return 42; } };
class B : public A
While I am working on prefetching-incurred performance degradation on
168.wupwise, I find that complex arrays are always over-prefetched.
Prefetches are generated for both the real part and imagine part.
subroutine s311 (i,j,n,m,beta,a,b)
c
c reductions
c sum reduction
c
intege
--- Comment #22 from redi at gcc dot gnu dot org 2010-07-15 17:03 ---
I wonder if some of the dups are actually caused by not building gcc with
--enable-fully-dynamic-string which is needed on Snow Leopard, but wasn't done
by macports until recently: https://trac.macports.org/ticket/2223
--- Comment #21 from pinskia at gcc dot gnu dot org 2010-07-15 16:58
---
*** Bug 43493 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:58 ---
*** This bug has been marked as a duplicate of 42159 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-07-15 16:58
---
*** Bug 43277 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-07-15 16:58 ---
*** This bug has been marked as a duplicate of 42159 ***
--
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
--
--- 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 #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 #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
--libdir=/opt/local/lib/gcc4
--- 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 #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 tea
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
#include
#include
#include
#include
using namespace std;
void generateException(int whichException);
int main(int argc, char ** arg
--- 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
--- Comment #6 from redi at gcc dot gnu dot org 2010-07-15 16:45 ---
and please ... it's 2010, not ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- 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=21217&action=view)
A new patch
How about this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #5 from redi at gcc dot gnu dot org 2010-07-15 16:38 ---
This is why you should only include 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 , and
, as needed.
(In reply to co
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 #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
namespace {
struct g
{
g(){ std::cout << "t"; }
};
g one;
}
--- CUT
--- 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 #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=revision&revision=162160
The test passes with the following patch:
--- ../_clean/gcc/fortran/trans-decl.c 2010-07-15 18:05:19.
--- 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=21216&action=view)
A patch
I am testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- 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 #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 @@ ix86_function_arg_boun
--- 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 #1 from pinskia at gmail dot com 2010-07-15 16:02 ---
Subject: Re: New: #include 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"
wrote:
> Noticed while reading
> http://
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" > wrote:
Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
#include
evans:/abuild/jh/t
--- 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 sp
--- 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
Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
#include
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 #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
AssignedTo|unassigned
--- 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=21215&action=view)
dump with -m64 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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=21214&action=view)
dump with -m64 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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=21213&action=view)
dump with -m32 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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=21212&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44950
--- 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=21211&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44951
--- 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=21210&action=view)
different testcase, reduced
$ gcc -O2 -finline-functions testcase.c
testcase.c:37:1: error: caller edge frequency 1142
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
j...@evans:/abuild/jh/build-mozilla-debug/toolkit/crashreporter/google-breakpad/src/c
--- 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/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\" -DOSARCH=
--- 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
--- 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
---
This is about both C and C++.
gcc warns about a construction like i&2==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 #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
--- 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 #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 #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 #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=gcc&view=rev&rev=162221
Log:
2010-07-15 Janus Weil
PR fortran/44936
* reso
--- 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 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 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: g+
1 - 100 of 137 matches
Mail list logo
