Dear all,
Although I probably shouldn't have been so harsh calling this
mis-compiling, do you see any chance of back-porting this warning back
into the mainline?
P.S. The rationale of this exercise is of course that the switch,
being a goto in disguise needs careful attention, just like the
引述 Andrew Haley a...@redhat.com:
There is no reason in principle this shouldn't be part of gcc.
I think no-one has responded yet because they don't know what it would
be for, and how much work it would involve.
What compiler doing is: c - intermediate language - asm(ex. x86).
And then, c
Snapshot gcc-4.5-20100304 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100304/
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/trunk
Dear all,
I've been trying to define this instruction but am having
difficulties. This instruction does 3 things:
- Updates an internal accumulator (depending on two arguments)
- Returns the value of that update in an output register
- Updates the internal accumulator after that
I first
Maybe try this:
(define_insn myInst
[
(set (match_operand:DI 0 register_operand =r)
(unspec:DI [(match_operand:DI 1 register_operand r)
(match_operand:DI 2 register_operand r)
(reg:DI 66)] 5))
(set (reg:DI 66)
(unspec:DI [(match_operand:DI 1 register_operand r)
(match_operand:DI 2
Yeah that's what I had tried first but I get :
genextract: Internal error: abort in VEC_safe_set_locstr
And I can't seem to get rid of that error.
Any idea why this happens?
Jc
On Thu, Mar 4, 2010 at 6:28 PM, Andrew Pinski pins...@gmail.com wrote:
Maybe try this:
(define_insn myInst
[
On Thu, Mar 4, 2010 at 3:38 PM, Jean Christophe Beyler
jean.christophe.bey...@gmail.com wrote:
Yeah that's what I had tried first but I get :
genextract: Internal error: abort in VEC_safe_set_locstr
And I can't seem to get rid of that error.
Any idea why this happens?
Oh because the second
Hi,
I want to use the the wctype builtins ISWALPHA and the other ISW* functions to
handle the wide character string, but I get the following error:
/home/gcc/build/gcc/../../trunk/gcc/opts.c:1190: undefined reference to
`ISWALPHA'
collect2: ld returned 1 exist status
I have tried to grep
Hello. I'm actually an EFI engineer so this project is of great
interest to me. I would be willing to lend a hand off hours if this
goes through, so please keep me in the loop.
I think the biggest hurdle would be the c front end since EBC (EFI
byte code) introduces variable sized pointers as
--- Comment #7 from janus at gcc dot gnu dot org 2010-03-04 09:17 ---
(In reply to comment #6)
Without looking at the code yet, the matcher must see a space or double colon
after the word FINAL before matching it. If it sees anything else, its a
MATCH_NO not a MATCH_ERROR. If this
mich...@ubuntu:~/src/misc$ cat test.cpp
#include cstdlib
int main() {
int *x = new int();
x-~int();
exit(0);
}
mich...@ubuntu:~/src/misc$ g++ test.cpp -o test
test.cpp: In function int main():
test.cpp:4: error: expected class-name before int
test.cpp:4: error: expected
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-04 10:02
---
This is illegal. You want something like:
typedef int I;
I *x = new I();
x-I::~I();
which is explicitly allowed in 12.4/15. Other relevant references are 5.2.4/1
and 7.1.5.2, which says that a
--- Comment #8 from burnus at gcc dot gnu dot org 2010-03-04 10:12 ---
(In reply to comment #6)
Free or Fixed form is irrelevant. Fixed form may allow things like F I N AL
but it still must have :: (or : whitespace :) to match. (Also, the invalid
looking array qualifier in that
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-04 10:14 ---
From http://gcc.gnu.org/ml/fortran/2010-03/msg00020.html
Currently our default namelist behaviour allows extended reads.
In other words, reading extra data beyond that specified by the array
qualifiers in the
--- Comment #9 from burnus at gcc dot gnu dot org 2010-03-04 10:16 ---
From: F2003, 3.3.2 Fixed source form: Except in a character context, blanks
are insignificant and may be used freely throughout the program.
One possibility is simply to return MATCH_NO for fixed form code if one is
--- Comment #13 from mikpe at it dot uu dot se 2010-03-04 10:16 ---
With binutils-2.20.51.20100223, gcc-4.5-20090327 regresses libjava as described
here but gcc-4.5-20100225 does not.
Starting bisection on trunk (with 24+ hour build/test cycles, that's going to
take a while).
--
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-04 10:35 ---
(In reply to comment #9)
From: F2003, 3.3.2 Fixed source form: Except in a character context, blanks
are insignificant and may be used freely throughout the program.
I guess this is what triggered the famous quote
--- Comment #10 from burnus at gcc dot gnu dot org 2010-03-04 11:05 ---
(In reply to comment #9)
We turn off this behaviour with -std=f95 or higher.
Apparently this is not true for -std=f2008:
That's seems to be an (additional) bug ...
I am thinking the extended reads should be
--- Comment #11 from burnus at gcc dot gnu dot org 2010-03-04 11:22 ---
(In reply to comment #10)
To me the code in comment #8 looks completely insane and unreadable, but if
some crazy standards document says it's legal, then so be it :)
I think it dates back to punch cards; there it
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-03-04 11:24 ---
Patch submitted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00207.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43164
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-03-04 11:25 ---
Patch submitted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00207.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43191
--- Comment #23 from paolo dot carlini at oracle dot com 2010-03-04 11:59
---
I'm analyzing the remaining xfails. About generation_prohibited, for vector and
deque, I see the tests failing only on the two forms of erase. But in that
case, the Standard (*) says that: Throws: Nothing
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-04 12:06 ---
(In reply to comment #11)
I think it dates back to punch cards;
Yes, I've seen those. However, being born too late, I never had the chance to
use them :)
I wouldn't expect anyone to use F03 FINAL statements in
Between revisions 157150 and 157190 (likely the latter) it appeared the
following failures on *-apple-darwin*:
FAIL: gcc.c-torture/execute/20020412-1.c compilation, -O3 -g
UNRESOLVED: gcc.c-torture/execute/20020412-1.c execution, -O3 -g
FAIL: gcc.c-torture/execute/20040811-1.c compilation,
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-04 12:10 ---
Created an attachment (id=20018)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20018action=view)
assembly for r157190 (warning)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-04 12:12 ---
Created an attachment (id=20019)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20019action=view)
assembly for r157098 (no warning) of gcc.c-torture/execute/20040811-1.c
--
--- Comment #9 from spop at gcc dot gnu dot org 2010-03-04 12:13 ---
Subject: Bug 43209
Author: spop
Date: Thu Mar 4 12:12:50 2010
New Revision: 157217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157217
Log:
Fix PR43209: Do not decrease the cost of an IV candidate when the
--- Comment #10 from spop at gcc dot gnu dot org 2010-03-04 12:14 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from burnus at gcc dot gnu dot org 2010-03-04 12:40 ---
(In reply to comment #12)
(In reply to comment #11)
I think it dates back to punch cards;
Yes, I've seen those. However, being born too late, I never had the chance to
use them :)
I also saw them in some
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-04 13:25 ---
Subject: Bug 40761
Author: rguenth
Date: Thu Mar 4 13:25:27 2010
New Revision: 157225
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157225
Log:
2010-03-04 Richard Guenther rguent...@suse.de
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-04 13:25 ---
PRE issue fixed for 4.5, still latent on the 4.4 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-04 13:32 ---
Well, what's the precision for logical(4)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43252
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-04 13:39 ---
DW_AT_upper_bound can be either a constant, or exprloc, or reference (this
case), so if dsymutil chokes on it, it needs to be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #14 from janus at gcc dot gnu dot org 2010-03-04 13:42 ---
Subject: Bug 43244
Author: janus
Date: Thu Mar 4 13:42:06 2010
New Revision: 157226
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157226
Log:
2010-03-04 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #15 from janus at gcc dot gnu dot org 2010-03-04 13:58 ---
Fixed with r157226. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-03-04 14:55 ---
Patch submitted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00208.html
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2010-03-04 14:59 ---
Created an attachment (id=20020)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20020action=view)
Fixes this bug
This does all the right things, except that the array elements cannot yet be
referenced - another
--- Comment #4 from pault at gcc dot gnu dot org 2010-03-04 15:00 ---
Created an attachment (id=20021)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20021action=view)
Fixes this bug
This does all the right things, except that the array elements cannot yet be
referenced - another
--- Comment #15 from jason at gcc dot gnu dot org 2010-03-04 15:21 ---
Created an attachment (id=20022)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20022action=view)
patch to fix mangle41.C on darwin
Ah, it seems darwin doesn't define ASM_OUTPUT_DEF. Does this patch fix
[reg...@gamow tmp276]$ current-gcc -c -O2 small.c
small.c: In function 'int32func':
small.c:15:6: internal compiler error: in extract_range_from_assert, at
tree-vrp.c:1423
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Consider the following code:
module module_myobj
implicit none
type :: myobj
contains
procedure :: myfunc
end type
contains
function myfunc(this, status)
class(myobj), intent(in) :: this
integer, intent(out), optional :: status
character(len=80) ::
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-04 16:04 ---
(In reply to comment #0)
Apparently this only happens for type-bound character-valued functions (but
not
for subroutines or e.g. integer-valued functions).
Actually that is wrong. It does work with subroutines,
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-04 16:11 ---
Btw, I just checked an analogous example with a procedure pointer component
instead of a type-bound procedure, and this works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-04 16:14 ---
Confirmed.
D.2745_31 = ASSERT_EXPR D.2745_20, D.2745_20 != D.2745_20;
From the unfolded:
D.2747_21 = D.2745_20 == D.2745_20;
similar to an earlier bug I fixed (caused by useless-stmts pass remove).
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Summary|ICE in |[4.5
IPA-SRA changes DECL_ASSEMBLER_NAME by changing the function signature before
mangling which results in collisions (testcase reduced from OpenOffice):
class A {};
class B {};
static void *func (int n)
{
void *p;
if (p == 0) throw ::A ();
}
static void *func (int n, B const )
{
try {
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
During the review of the patch for PR libgcj/38251
PATCH: Avoid command line length limit building tools.zip (PR libgcj/38251)
http://gcc.gnu.org/ml/java-patches/2010-q1/msg00021.html
it was discovered that in-tree builds are most likely broken in
libjava/classpass/tools due to those
As described in
PATCH: Use __gthread_mutex_t in profile/impl/profiler_trace.h
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00996.html
there's one remaining libstdc++ testsuite failure on Solaris 11/x86:
FAIL: ext/profile/all.cc (test for excess errors)
The error is:
Excess errors:
In file
Consider:
class jvstatic
{
public static int STATIC = 1;
public static final int CONST_STATIC = 2;
public static void main (String[] args)
{
int i;
for (i = 0; i STATIC + CONST_STATIC; ++i)
System.out.println (Hi!);
}
}
The DWARF debug info for either jvstatic.STATIC or
--- Comment #2 from dodji at gcc dot gnu dot org 2010-03-04 17:44 ---
I am testing a patch for this ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43206
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-04 17:44 ---
The problematic line expands to:
static pthread_mutex_t __global_lock(PTHREAD_MUTEX_INITIALIZER);
which is clearly wrong when PTHREAD_MUTEX_INITIALIZER is of the form {...}
As you suggest, it should be using
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-04 17:45
---
Same on SPARC/Solaris 10:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00295.html
Present on SPARC/Solaris 9:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00294.html
but the error is different:
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-04 17:56 ---
Another patch - please try!
Index: libgfortran.h
===
--- libgfortran.h (revision 157215)
+++ libgfortran.h (working copy)
@@ -121,2 +121,9
I work on a library compiled with gcc4.0 and old versions. I want to insert
OpenMP directives in the source code. So I compiled the code with gcc4.4
version since openmp is recognized that from version 4.2, but I get many
errors especially at the Definiton of templates. So I want to know what is
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-03-04 18:16 ---
Subject: Bug 43191
Author: jamborm
Date: Thu Mar 4 18:16:32 2010
New Revision: 157232
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157232
Log:
2010-03-04 Martin Jambor mjam...@suse.cz
PR
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-03-04 18:16 ---
Subject: Bug 43164
Author: jamborm
Date: Thu Mar 4 18:16:32 2010
New Revision: 157232
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157232
Log:
2010-03-04 Martin Jambor mjam...@suse.cz
PR
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-03-04 18:17 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-03-04 18:17 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from manu at gcc dot gnu dot org 2010-03-04 18:22 ---
REOPENing as a diagnostic enhancement. I know that the quality of the
diagnostics from the parser is not a top priority but I still hop that someone
may someday improve this a little. And this error could be so much
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-03-04 18:22 ---
(In reply to comment #2)
This is most likely a dup of bug 42450.
Indeed it is.
*** This bug has been marked as a duplicate of 42450 ***
--
jamborm at gcc dot gnu dot org changed:
What
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-03-04 18:22
---
*** Bug 43198 has been marked as a duplicate of this bug. ***
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jamborm at gcc dot gnu dot org 2010-03-04 18:24
---
I have a patch for this. I will submit it tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
--- Comment #9 from manu at gcc dot gnu dot org 2010-03-04 18:29 ---
I am reopening as an enhancement request because all this discussion could be
better summarized in the error message (in particular, the part about A being
injected in B and being private).
clang has a fixit/extra
--- Comment #3 from reza dot yazdani at amd dot com 2010-03-04 18:37
---
I reduced the test to:
--
extern void abort (void);
__attribute__ ((noinline)) int
foo (int *zzz, unsigned int kk)
{
int a, b, d;
a = b = 0;
for (d = 0; d 1000; d++)
{
if
--- Comment #12 from bergner at gcc dot gnu dot org 2010-03-04 19:08
---
This bug was fixed with Jeff Law's commit (revision 157168) of the patch
attached to the Patch URL listed above.
--
bergner at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-04 19:09 ---
(In reply to comment #4)
+/* MinGW needs to use the gnu_printf formatter. */
+#if __MINGW32__
+# define PRINTF_FORMAT gnu_printf
+#else
+# define PRINTF_FORMAT printf
+#endif
Note I would do:
+/* MinGW
--- Comment #9 from tkoenig at gcc dot gnu dot org 2010-03-04 19:40 ---
Should we also commit the test case from #4 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
--- Comment #7 from jdecs at mssblue dot net 2010-03-04 19:56 ---
Original poster agrees - latest version of XMLAda solves problem (along with
latest gcc) - Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37572
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-04 19:59 ---
Subject: Bug 43248
Author: pinskia
Date: Thu Mar 4 19:59:19 2010
New Revision: 157233
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157233
Log:
2010-03-04 Andrew Pinski andrew_pin...@caviumnetworks.com
--- Comment #13 from bergner at gcc dot gnu dot org 2010-03-04 19:59
---
I verified this is fixed with a fresh checkout of mainline.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-04 20:00 ---
Fixed on the trunk so far.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
On Thu, Mar 4, 2010 at 10:16 AM, hannibal81 jallo...@yahoo.fr wrote:
templatetypename P, templatetypename T class ST=std::vector
std::vector has two template arguments not just one. One of them has
a default value though. But the C++ standard requires that the number
of template arguments to
Dependant name shall be look up at the point of instantiation.
But for names that depends on Variadic Template Parameter, are looked up at the
point of definition.
Following code is well-formed. and shall be compiled.
template typename T, typename ... Args
void f(T, Args... rest)
{// point of
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-04 20:24 ---
Or is it? This comes down to fundamental types having what namespace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43261
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-04 20:28
---
*** Bug 43261 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-04 20:28 ---
*** This bug has been marked as a duplicate of 29131 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-04 20:48 ---
*** This bug has been marked as a duplicate of 7652 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-04 20:48 ---
*** Bug 43250 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-03-04 21:14 ---
Ok, think I got it. It's a one-liner:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157225)
+++ gcc/fortran/resolve.c
I put here a simple example to illustrate what looks like a bug to me
#includeiostream
inline unsigned next_exp2(unsigned x)
{
unsigned n;
asm volatile(bsr %0, %1 : =r (n) : r (x)); // most significant
bit
return((x == (1u n)) ? n : n);
};
inline unsigned
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-04 22:08 ---
The problem you are seeing is Intel vs ATT asm formats. GNU as defaults to
ATT format in that it is src, dst. So you have the operands swapped. Note
also you also don't clobber the flags register as bsr sets the
--- Comment #4 from janus at gcc dot gnu dot org 2010-03-04 22:10 ---
(In reply to comment #3)
Hope this produces no regressions.
Unfortunately it does :(
FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for
I put here a simple example to illustrate what looks like a bug to me
#includeiostream
inline unsigned next_exp2(unsigned x)
{
unsigned n;
asm volatile(bsr %0, %1 : =r (n) : r (x)); // most significant
bit
return((x == (1u n)) ? n : n);
};
inline unsigned
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-04 22:24 ---
*** Bug 43263 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43262
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-04 22:24 ---
*** This bug has been marked as a duplicate of 43262 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from s dot v dot savenko at gmail dot com 2010-03-04 22:26
---
You're absolutely right. Sorry for the false alarm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43262
--- Comment #12 from spop at gcc dot gnu dot org 2010-03-04 22:27 ---
We are building scalar evolutions that have no defined semantics:
the initial value is variating in an inner loop.
{(2 + (integer(kind=4)) {0, +, 1}_5) * 5 + ((2 + (integer(kind=4)) {0, +, 1}_4)
+ -6), +, 6}_1
and
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-04 22:44 ---
(In reply to comment #4)
FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-03-05
00:48 ---
The patch doesn't allow a bootstrap. I get...
/sw/src/fink.build/gcc45-4.4.999-20100304/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100304/darwin_objdir/./prev-gcc/
-B/sw/lib
--- Comment #3 from boostcpp at gmail dot com 2010-03-05 00:55 ---
Thank you. Now I understand the real problem.
But still, it's nasty.
I wonder C++0x fix this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43261
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-05 00:57 ---
(In reply to comment #3)
Thank you. Now I understand the real problem.
But still, it's nasty.
I wonder C++0x fix this issue.
Considering the defect report against the C++ standard is still on the active
list, I
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-03-05
02:31 ---
Created an attachment (id=20023)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20023action=view)
revised mangle-darwin patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-03-05
02:33 ---
(In reply to comment #17)
Created an attachment (id=20023)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20023action=view) [edit]
revised mangle-darwin patch
This revised patch bootstraps on
I use h8300-elf.
When this is executed, the value is 65536.
If there is optional optimization (-O1), the value is 0.
command
--
u...@user-laptop:~/study$ /usr/local/gcc-4.4.3_h8300-elf/bin/h8300-elf-gcc
h8300_error.c
u...@user-laptop:~/study$
--- Comment #1 from n-takeda at kwansei dot ac dot jp 2010-03-05 04:18
---
Created an attachment (id=20024)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20024action=view)
c program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43264
--- Comment #2 from n-takeda at kwansei dot ac dot jp 2010-03-05 04:19
---
Created an attachment (id=20025)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20025action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43264
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-05 05:30 ---
What is the size of long on h8300-elf?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
In at least 4.4.2 and 4.4.3, a jump on read trick that worked in 4.2.4 and
4.3.4, and with ifort 10,11 and numerous others, no longer works.
[...@rscpc28 ReadTest]$ cat log
line 1
line 2
line 3
[...@rscpc28 ReadTest]$ cat fred.f90
program fred
implicit none
integer::i
open(2,file='log')
do
1 - 100 of 102 matches
Mail list logo
