--- Comment #9 from ghazi at gcc dot gnu dot org 2009-12-08 08:08 ---
Jack, what does this program do on darwin9 and darwin10?
(The correct output is "2 0".)
int main(void)
{
volatile _Complex double val = (__DBL_MAX__ * 0.5 + __DBL_MAX__ * 0.5i);
val /= (__DBL_MAX__ * 0.25 + __DBL_
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-08 08:24 ---
Yeah, this isn't VTA related.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-12-08 08:52 ---
Subject: Bug 40961
Author: burnus
Date: Tue Dec 8 08:52:28 2009
New Revision: 155083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155083
Log:
2009-12-08 Tobias Burnus
PR fortran/40961
P
--- Comment #4 from burnus at gcc dot gnu dot org 2009-12-08 08:52 ---
Subject: Bug 40377
Author: burnus
Date: Tue Dec 8 08:52:28 2009
New Revision: 155083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155083
Log:
2009-12-08 Tobias Burnus
PR fortran/40961
P
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-08 08:53 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-08 08:53 ---
FIXED
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-12-08
08:56 ---
with the proposed patch applied, the build fails now with:
virtual __gnu_cxx::stdio_sync_filebuf::~stdio_sync_filebuf()/243(191)
@0x4093abd0 availability:available 22 time, 11 benefit (
24 after inlining) 4
--- Comment #3 from debian-gcc at lists dot debian dot org 2009-12-08
08:58 ---
Created an attachment (id=19256)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19256&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42317
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-08 09:03 ---
You were testing the patch attached here (i.e. version before
bootstrap/regtest) instead of the one posted to gcc-patches (tested), right?
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00385.html
--
http://gcc.gnu.
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-08 09:18
---
*** Bug 42330 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-08 09:18
---
You aren't defining anywhere A::i, just add, after struct A:
const int A::i;
and things will be fine.
*** This bug has been marked as a duplicate of 42101 ***
--
paolo dot carlini at oracle dot com cha
--- Comment #6 from olga at gcc dot gnu dot org 2009-12-08 09:41 ---
Subject: Bug 41843
Author: olga
Date: Tue Dec 8 09:41:13 2009
New Revision: 155084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155084
Log:
2009-12-07 Olga Golovanevsky
PR middle-end/41843
--- Comment #2 from aijunbai at gmail dot com 2009-12-08 09:46 ---
(In reply to comment #1)
> You aren't defining anywhere A::i, just add, after struct A:
>
> const int A::i;
>
> and things will be fine.
>
> *** This bug has been marked as a duplicate of 42101 ***
>
thanks for you
--- Comment #3 from redi at gcc dot gnu dot org 2009-12-08 09:48 ---
(In reply to comment #2)
> and i don't want to write lots of "const int A::i"...
You have to, your code is not valid if you use A::i in the program but it has
no definition. This is not a compiler bug.
*** This bu
--- Comment #11 from redi at gcc dot gnu dot org 2009-12-08 09:48 ---
*** Bug 42330 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-08 09:50 ---
(In reply to comment #3)
> (In reply to comment #2)
> > and i don't want to write lots of "const int A::i"...
>
> You have to, your code is not valid if you use A::i in the program but it has
> no definition. This is
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-08 09:53
---
This is yet another, C++0x, in this case, testcase, as provided by Jon. I
believe it's the same obnoxious mangling issue, but an additional testcase
cannot hurt ;)
#include
unsigned value = 0;
struct Inc {
--- Comment #10 from dominiq at lps dot ens dot fr 2009-12-08 09:56 ---
I had a look at the problem and found that it is due to the -lm flag used in
the test suite. The test in comment #9 gives for x86_64-apple-darwin10:
[macbook] f90/bug% a.out
2 0
[macbook] f90/bug% gcc45 pr42074.c -
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-08 09:57 ---
What's wrong with
class baz : protected freeList {
voidfrob() {}
friend class freeList;
};
or
class baz : protected freeList {
voidfrob() {}
template friend void freeList::foo();
--- Comment #9 from dominiq at lps dot ens dot fr 2009-12-08 10:06 ---
I have bootstrapped gcc revision 155054 with the mpc version for which the
tests passed (revision 154405) and the tests are still failing.
The minimal set of options to make the test in comment #6 abort is "-O1
-funr
--- Comment #7 from olga at il dot ibm dot com 2009-12-08 10:19 ---
With this patch running shape.i produces the following output:
Using built-in specs.
COLLECT_GCC=/home/olga/mainline_after_LTO_merge-bin/bin/gcc
COLLECT_LTO_WRAPPER=/home/olga/mainline_after_LTO_merge-bin/libexec/gcc/po
--- Comment #2 from viriketo at gmail dot com 2009-12-08 10:26 ---
Sorry, I noticed that the libtsdc++ build does not help in this case, because
it is build with -nostdlib, and the startfile objects are determined by the
configure script. It is a special case of linking, not to be compar
--- Comment #13 from redi at gcc dot gnu dot org 2009-12-08 10:48 ---
(In reply to comment #12)
> > The situation will be different with the upcoming C++1x standard where there
> > is null_ptr.
>
> Yes, very different. Per the accepted language defect and paper I cited here
> yesterday
seen with trunk 20091208 and 4.4 branch 20091130, not with 4.3.4:
$ g++ -g Mesh.ii
In file included from /usr/include/c++/4.4/ext/new_allocator.h:34,
from
/usr/include/c++/4.4/x86_64-linux-gnu/bits/c++allocator.h:35,
from /usr/include/c++/4.4/bits/allocator.h:49
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-08 11:01
---
We are still missing Mesh.ii. And, please, do your best to reduce it before
attaching it, thanks in advance...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #2 from doko at ubuntu dot com 2009-12-08 11:04 ---
Created an attachment (id=19257)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19257&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42331
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-08 11:06
---
Thanks ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42331
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last re
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.4.3
http://gcc
--- Comment #4 from doko at ubuntu dot com 2009-12-08 11:08 ---
sorry, didn't see the comment before attaching the file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42331
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-08 11:14
---
No problem. Please, try to figure out something small, shouldn't be that
difficult, I think it should involve only 'int typele[7][2]' vs 'typele={0}'
--
paolo dot carlini at oracle dot com changed:
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-08 11:19
---
This is enough:
class Mesh
{
public:
Mesh(const char*)
{ typele={0}; }
private:
int typele[7][2];
};
Mesh m(0);
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2009-12-08 11:19:20 |2009-12-08 1
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-08 11:21 ---
'typename X::T*' is a non-deduced context, so should not be involved in
argument deduction, and 0 is a valid null pointer constant
*** This bug has been marked as a duplicate of 23055 ***
--
redi at gcc dot gnu do
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-08 11:21 ---
*** Bug 29577 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from paolo dot carlini at oracle dot com 2009-12-08 11:21
---
Let's CC Jason, maybe it's just matter of robustifying a tad the initializer
list code.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #5 from domob at gcc dot gnu dot org 2009-12-08 11:39 ---
Subject: Bug 41177
Author: domob
Date: Tue Dec 8 11:39:20 2009
New Revision: 155086
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155086
Log:
2008-12-08 Daniel Kraft
PR fortran/41177
* gf
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-12-08 11:41 ---
(In reply to comment #3)
> Created an attachment (id=19235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19235&action=view) [edit]
> Diff file
>
> This allows me to compile it, but quoting from windef.h: /* FI
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|domob at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #6 from domob at gcc dot gnu dot org 2009-12-08 11:45 ---
This fixes most of the issues mentioned, except that it does not yet allow
calling an ELEMENTAL type-bound procedure on a non-scalar base object; this
leads to an ICE and thus I disabled it for now. I'll keep on worki
--- Comment #13 from ramana at gcc dot gnu dot org 2009-12-08 11:47 ---
I see this with last night's trunk on a native armv5te linux machine with 512MB
of RAM.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from domob at gcc dot gnu dot org 2009-12-08 11:48 ---
Created an attachment (id=19258)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19258&action=view)
Test case for ELEMENTAL type-bound procedure call
This is a test-case for the still missing part as per the last
--- Comment #5 from aijunbai at gmail dot com 2009-12-08 11:52 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > and i don't want to write lots of "const int A::i"...
> >
> > You have to, your code is not valid if you use A::i in the program but
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-12-08 11:54
---
It needs 60MB on i?86-linux with -O2 -g -fschedule-insns. Thus this is a
target specific problem. Is the arm automaton particularly large?
--
rguenth at gcc dot gnu dot org changed:
What|Remov
--- Comment #4 from amonakov at gcc dot gnu dot org 2009-12-08 11:55
---
(In reply to comment #3)
> Also not reproducible on x86_64->ppc64 cross.
> While codegen differences on ppc/ppc64/x86_64 cross are certainly surprising,
> in the end this testcase most likely indicates a bug in sel
--- Comment #2 from zsojka at seznam dot cz 2009-12-08 12:19 ---
Created an attachment (id=19259)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19259&action=view)
reduced testcase
pr42325-reduced.cpp:2:27: error: template parameters not used in partial
specialization:
pr42325-redu
--- Comment #6 from redi at gcc dot gnu dot org 2009-12-08 12:23 ---
(In reply to comment #5)
> >
> > template const A::i;
> >
>
> I tried so, but it seems do not work, could you please explain more
> detailedly?
> thx~
I missed the "int" out:
template const int A::i;
--
http:
--- Comment #5 from doko at ubuntu dot com 2009-12-08 12:36 ---
yes, re-testing with the version from the ML. currently passed the libstdc++
build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42317
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-12-08
12:37 ---
*** This bug has been marked as a duplicate of 42317 ***
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
-
--- Comment #6 from debian-gcc at lists dot debian dot org 2009-12-08
12:37 ---
*** Bug 42323 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42317
--- Comment #7 from aijunbai at gmail dot com 2009-12-08 13:02 ---
(In reply to comment #6)
> (In reply to comment #5)
> > >
> > > template const A::i;
> > >
> >
> > I tried so, but it seems do not work, could you please explain more
> > detailedly?
> > thx~
>
> I missed the "int" o
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-08 13:11
---
Likely a duplicate of PR34491.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-08 13:12
---
Then show here exactly what you are trying to compile. Note: this is *not*
gcc-help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42330
--- Comment #45 from matz at gcc dot gnu dot org 2009-12-08 13:56 ---
Subject: Bug 38474
Author: matz
Date: Tue Dec 8 13:56:06 2009
New Revision: 155087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155087
Log:
PR middle-end/38474
* function.c (free_temp_slots)
While compiling a simple class containing a std::tr1::unordered_map member as a
library, linking to the library and creating an object generate illegal
hardware instruction. Or at least, running the code raise a SIGILL. The library
file is lib.cc and the main program is test_lib.cc. The commands us
--- Comment #1 from pbdr at uea dot ac dot uk 2009-12-08 14:00 ---
Created an attachment (id=19260)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19260&action=view)
preprocessed file for the library
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
--- Comment #2 from pbdr at uea dot ac dot uk 2009-12-08 14:00 ---
Created an attachment (id=19261)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19261&action=view)
preprocessed file for the main program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
--
pbdr at uea dot ac dot uk changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
--- Comment #9 from aijunbai at gmail dot com 2009-12-08 14:06 ---
(In reply to comment #8)
> Then show here exactly what you are trying to compile. Note: this is *not*
> gcc-help.
>
alright, take the flowing code as an example:
template
struct A {
static const int i = -1;
};
tem
--- Comment #24 from burnus at gcc dot gnu dot org 2009-12-08 14:12 ---
Subject: Bug 41711
Author: burnus
Date: Tue Dec 8 14:12:06 2009
New Revision: 155088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155088
Log:
2009-12-08 Tobias Burnus
PR fortran/41711
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-08
14:13 ---
Mike Stump says that the frame can be optimized away on darwin. However,
Apple's 4.2.1 compiler in darwin10 also appears to leave the stack frame...
[MacPro:~/bug] howarth% gcc-4.2 -O2 -fomit-frame-point
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-08 14:15
---
Since you have specializations for A, you also need, in general, the
corresponding definitions:
const int A<0>::i;
const int A<1>::i;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42330
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-12-08 14:16
---
After removing a couple of lines from the preprocessed code I end up with the
same problem as in PR41290. Apparently this bug hasn't been fixed and still
haunts us.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #25 from burnus at gcc dot gnu dot org 2009-12-08 14:25 ---
STATUS:
* Writing large-kind real/complex numbers works (cf. comment 10)
* Reading large-kind real/complex numbers works on systems which have
INTEGER(16) (cf. comment 24, which added REAL(10) support)
* For the s
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-08 14:30 ---
Is your CPU SSE4 capable? cat /proc/cpuinfo would reveal this.
Can you post disassembly at the point of SIGILL (run it under gdb,
p/x $pc
disas $pc-64 $pc+64
info reg
when it crashes?
--
jakub at gcc dot gnu dot or
--- Comment #4 from pbdr at uea dot ac dot uk 2009-12-08 14:35 ---
Mmmhh ... indeed ... I really though my processor for sse4, but it doesn't seem
to be. Sorry about such a bad mistake.
--
pbdr at uea dot ac dot uk changed:
What|Removed |Added
--- Comment #4 from dodji at gcc dot gnu dot org 2009-12-08 14:44 ---
A shorter reproducer is:
struct foo
{
static const bool b = false;
};
template
struct S1
{
};
template
struct S2
: S1
{
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
--- Comment #5 from dodji at gcc dot gnu dot org 2009-12-08 14:45 ---
Created an attachment (id=19262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19262&action=view)
Candidate patch
I am testing this patch currently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
--- Comment #5 from igodard at pacbell dot net 2009-12-08 15:20 ---
Both proposals befriend more than the minimum actually needed by program
semantics. The former befriends any member of freeList, not just foo;
the latter any member of any freeList at all. In addition, the former require
--- Comment #6 from dodji at gcc dot gnu dot org 2009-12-08 15:52 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00438.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-12-08 15:57 ---
So we have new direct call appearing to function that has been previously
eliminated as unreachable (after inlining) as a result of devirtualization?
In general if function have address taken, we should not remove i
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-12-08 16:01 ---
I assumed it is special vtable handling (that likely doesn't cause the
addressable flag to be set?) - I simply stopped debugging at the point
where I noticed the node gets removed even though there are still
indirect
As noted in PR42074, linking with the math library on darwin10 allows overflow
to occur during complex division. It was originally reported as a failure in
testcase gcc.dg/torture/builtin-math-7.c at all optimization levels. However
as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4207
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-08 16:33 ---
> As such, it isn't necessarily a bug in GCC, however
> this PR will help track if there is a possible workaround.
As far as I understand the use of the gcc compilers on darwin, I do not see
when I should use -lm.
So
--- Comment #10 from hubicka at ucw dot cz 2009-12-08 16:35 ---
Subject: Re: [4.5 Regression] ICE with inlining
> I assumed it is special vtable handling (that likely doesn't cause the
> addressable flag to be set?) - I simply stopped debugging at the point
> where I noticed the node g
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-12-08 16:35 ---
(In reply to comment #10)
> I had a look at the problem and found that it is due to the -lm flag used in
> the test suite. [...]
> and tgcc.dg/torture/builtin-math-7.c passes when it is compiled manually
> without -lm
--- Comment #11 from hubicka at gcc dot gnu dot org 2009-12-08 16:36
---
Testing patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-12-08 16:46 ---
(In reply to comment #1)
> > As such, it isn't necessarily a bug in GCC, however
> > this PR will help track if there is a possible workaround.
> As far as I understand the use of the gcc compilers on darwin, I do not
--- Comment #26 from jsm28 at gcc dot gnu dot org 2009-12-08 17:08 ---
List of remaining target OSes without stdint.h type information added
to 4.5 release notes:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00441.html
NetBSD, VxWorks, VMS, SymbianOS, WinCE, LynxOS, Netware, QNX, Interi
--- Comment #5 from daney at gcc dot gnu dot org 2009-12-08 17:34 ---
(In reply to comment #4)
> Mike Stump says that the frame can be optimized away on darwin. However,
> Apple's 4.2.1 compiler in darwin10 also appears to leave the stack frame...
That compiler doesn't implement __buil
--- Comment #5 from tromey at gcc dot gnu dot org 2009-12-08 17:58 ---
FWIW, I know that this patch will not affect the CVS gdb,
because that gdb never reads the .debug_aranges section.
I'll try this out using my branch today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288
--- Comment #7 from hjl dot tools at gmail dot com 2009-12-08 18:17 ---
Another testcase:
[...@gnu-26 pr42324]$ cat b3.c
void foo (unsigned long, unsigned int, unsigned long,
unsigned int, unsigned int, unsigned int, unsigned int,
unsigned long, unsigned int);
void
--- Comment #8 from hjl dot tools at gmail dot com 2009-12-08 18:26 ---
Both icc and gcc generate:
[...@gnu-26 pr42324]$ cat b4.c
extern unsigned int bartmp;
void foo(_Bool bar)
{
bartmp = bar;
}
[...@gnu-26 pr42324]$ objdump -dw b4.o
b4.o: file format elf64-x86-64
Disassembly
--- Comment #3 from dominiq at lps dot ens dot fr 2009-12-08 18:31 ---
(In reply to comment #2)
> I don't think that's the right approach, that would only mask the bug in the
> testsuite but leave it in userland. ...
You are right, but from what follows I think the problem comes from th
GCC trunk gets a segmentation fault when building SPEC CPU2000 test
200.sixtrack with "-floop-interchange -ftree-loop-distribution" on
powerpc-linux, as demonstrated by this minimized testcase:
subroutine blockdis(bl1eg,bl2eg)
implicit real*8 (a-h,o-z)
parameter(nblo=300)
c
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-08
19:30 ---
Dominique,
It would be interesting to know what happens with a build of gcc trunk
under darwin10 if you regress out the r154282 and r154283 that introduced the
libgcc_ext feature . I suspect this regres
--- Comment #5 from dominiq at lps dot ens dot fr 2009-12-08 19:34 ---
Additional information:
(1) I don't see the problem on (i686|x86_64)-apple-darwin9.
(2) I also see it gcc version 4.4.2 (GCC).
(3) I don't see it with gcc version 4.2.1 (Apple Inc. build 5646) (dot 1).
(3) If I co
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-08 19:51 ---
I think this comes down to an alignment issue. On darwin, the stack has to be
aligned to 16bytes so something inside i386.c is deciding that we to allocate
the stack frame as there was something on the stack and we h
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-08
19:59 ---
Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
unclear what that test should do there. Try reverting out the libgcc_ext
changes from gcc trunk on darwin10 instead.
--
http://g
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:21 ---
There's been an XFAIL about this in g++.old-deja/g++.jason/cond.C for ages, but
it doesn't test the switch case.
Self-contained testcase:
void f() {
if (int foo = 0)
int foo = 1;
switch (int foo = 0)
{
de
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-08 20:24 ---
*** This bug has been marked as a duplicate of 18770 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-12-08 20:24 ---
*** Bug 31956 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-12-08 20:24 ---
(In reply to comment #6)
> Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
> unclear what that test should do there.
Jack - Focusing on builtin-math-7.c (which tests multiple things) misses t
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-12-08
20:27 ---
(In reply to comment #6)
A *Very* quick look following a prompt from Jack...
> Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
> unclear what that test should do there. Try re
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:32 ---
reduced:
void f() {
unsigned short i = 0;
void* p = (void*)i;
}
this warns in 32-bit or 64-bit mode using the C compiler, and is controlled by
this option that g++ doesn't support:
-Wno-int-to-pointer-cast (C and O
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-12-08 20:32
---
This really is not a duplicate of PR20923. In fact the gfortran frontend makes
it through the fft257.f90 test case in a few seconds. The memory hogging and
cycling is happening in middle-end.
With a simple vari
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-08 20:33 ---
(In reply to comment #0)
> ! The following is illegal!
> type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )
I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the
example (figure 12.3
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:45 ---
diagnosing this would be useful and shouldn't require instantiation, it should
be detectable during phase 1
reduced:
struct foo {
template foo(int);
};
--
redi at gcc dot gnu dot org changed:
What
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-12-08
20:51 ---
> version 125.0.0)
> /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0,
> current version 315.0.0)
> [macbook] f90/bug% nm /usr/lib/libSystem.B.dylib | grep divdc3
> 0019fa1e S
1 - 100 of 145 matches
Mail list logo
