--- Comment #1 from irar at il dot ibm dot com 2007-02-22 07:58 ---
Here is the ChangeLog entry for that patch:
2007-02-09 Richard Henderson [EMAIL PROTECTED]
* config/i386/constraints.md (Ym): New constraint.
* config/i386/i386.md (movsi_1): Change Y2 to Yi
--- Comment #2 from ubizjak at gmail dot com 2007-02-22 08:11 ---
(In reply to comment #0)
Bootstrap with vectorization enabled fails on i386 starting from revision
121767:
http://gcc.gnu.org/viewcvs?view=revrevision=121767
Could you post exact steps how to reproduce this failure?
--- Comment #10 from dorit at gcc dot gnu dot org 2007-02-22 08:16 ---
Subject: Bug 30858
Author: dorit
Date: Thu Feb 22 08:16:18 2007
New Revision: 10
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=10
Log:
PR tree-optimization/30858
* tree-vectorizer.c
--- Comment #3 from irar at il dot ibm dot com 2007-02-22 08:22 ---
(In reply to comment #2)
(In reply to comment #0)
Bootstrap with vectorization enabled fails on i386 starting from revision
121767:
http://gcc.gnu.org/viewcvs?view=revrevision=121767
Could you post exact steps
--- Comment #1 from bonzini at gnu dot org 2007-02-22 08:27 ---
It's actually a small oversight in fwprop, which is supposed to replace
find_best_addr indeed.
The patch indicated in the URL is enough for dataflow-branch; on mainline you
need also
--- Comment #7 from bonzini at gnu dot org 2007-02-22 08:41 ---
Now that the patch has been applied to dataflow branch, this remains as a
missed optimization on the tree level.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #18 from peb at mppmu dot mpg dot de 2007-02-22 08:58 ---
I have tried to analyze the cause of the -L flags passed to libtool when
linking libsupc++ and libstdc++ and found these two:
(1) explicit flags in the top-level RAW_CXX_FOR_TARGET passed as CXX to the
libstdc++ and
IMPORT fails, if one imports the same symbol in multiple interface bodies of
same interface block.
Found by Christopher D. Rickett,
http://gcc.gnu.org/ml/fortran/2007-02/msg00466.html
Test case:
module test_import
implicit none
type :: my_type
Cf. http://gcc.gnu.org/ml/fortran/2007-02/msg00145.html
The following code is invalid Fortran as the USE-associated NAMELIST is
respecified in the main program:
MODULE debug
LOGICAL debug_area
NAMELIST/debugging/debug_area
END MODULE debug
PROGRAM ding
USE
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-22 09:30 ---
(In reply to comment #1)
This fixes it:
Index: gcc/fortran/check.c
===
*** gcc/fortran/check.c (revision 122101)
--- gcc/fortran/check.c (working copy)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-22 09:35 ---
This is a regression on the 4.1 branch. For reference, the valid testcase is
class QGList;
unsigned count()
{
class QGListIterator {
friend class QGList;
QGListIterator( const QGList );
};
}
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-22 09:41 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #4 from ubizjak at gmail dot com 2007-02-22 09:54 ---
Confirmed, the bootstrap breaks with;
/home/uros/gcc-i386/./gcc/xgcc -B/home/uros/gcc-i386/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include
A quite simple array specialization construct is rejected by g++ with a
compiler error message. Not being a language specialist icc 9.1 accepts the
code even with -strict-ansi flag. Allegedly also comeau accepts the code. The
g++ compiler error message is also pretty strange and indicates a
--- Comment #1 from enok at lysator dot liu dot se 2007-02-22 10:16 ---
I'm unable to create attachments, bugzilla crashes. I have reported the
bugzilla bug also to [EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30924
--- Comment #3 from bonzini at gnu dot org 2007-02-22 10:20 ---
This will also appear in mainline when the patch for PR30841 is applied
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
--- Comment #3 from ubizjak at gmail dot com 2007-02-22 11:04 ---
These warnirngs disappear by commenting out TARGET_HAS_SINCOS in
config/linux.h.
These warnings indeed point to pov::create_ray, where we have quite some tree
sincos transformations:
int pov::create_ray(pov::RAY*,
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-22 11:04 ---
Confirmed. Whoever wrote that code should be
typedef long unsigned int size_t;
typedef signed int sal_Int32;
typedef unsigned int sal_uInt32;
typedef unsigned long int sal_uInt64;
extern C void *memcpy (void
When trying to compile test.cpp:
'
namespace {
struct A
{
A() {}
explicit A(short i) :m_value(i) {}
A operator = (short i) {
m_value = i;
return *this;
}
operator short () { return m_value; }
operator short () const { return m_value; }
private:
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-02-22 11:25
---
Confirmed. Whoever wrote that code should be
You meant whoever wrote a compiler which accepts that code..., right. :-)
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-22 12:21 ---
Dough - how is the middle-end supposed to handle this? The case in question
get's a
double sin(double)
and wants to build
_Complex double cexpi(double)
It now uses tree.c:build_complex_type which seems to fix
--- Comment #8 from irar at gcc dot gnu dot org 2007-02-22 12:30 ---
Subject: Bug 30843
Author: irar
Date: Thu Feb 22 12:30:12 2007
New Revision: 15
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=15
Log:
PR tree-optimization/30843
* tree-vect-transform.c
--- Comment #5 from pmason at ricardo dot com 2007-02-22 12:40 ---
Get same problem with equivalent P/E format:
write(6,'(1pe6.0)') 1.0e-1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
--- Comment #6 from burnus at gcc dot gnu dot org 2007-02-22 13:50 ---
I think I found why the output is wrong. The following condition has been
introduced 2006-08-27 with the patch
http://gcc.gnu.org/viewcvs?view=revrevision=116502
Before the if the value is 0.1, afterwards it is 0.0.
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-22 13:59 ---
Forget to mention: If I comment out that if-block, the output is correct
(1.E-01). Now you need only to fix it without breaking the other PR ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-02-22 14:23
---
Thanks Tobias. I suspected a connection with that patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
--- Comment #5 from ian at gcc dot gnu dot org 2007-02-22 14:55 ---
Subject: Bug 30898
Author: ian
Date: Thu Feb 22 14:55:09 2007
New Revision: 18
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=18
Log:
./:
PR debug/30898
* dwarf2out.c
--- Comment #3 from swagiaal at redhat dot com 2007-02-22 15:11 ---
Expected:
The collection quota (500 objects) is met and the program exits with a pass
Actual;
The program hangs before the quota is met. Some times not a single object is
collected.
This happens more frequently
--- Comment #4 from aph at gcc dot gnu dot org 2007-02-22 15:19 ---
I can't see anything in the Java Language Standard that suggests that your test
case must terminate. Garbage collection is not deterministic, and may not
collect all objects.
When I tried your test case one object was
--- Comment #5 from swagiaal at redhat dot com 2007-02-22 15:35 ---
Fare enough, I just thought I would bring my test case to your attention.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30886
--- Comment #19 from bfriesen at simple dot dallas dot tx dot us
2007-02-22 15:58 ---
(In reply to comment #8)
Note that, on PA, the linker does indeed annotate an executable with the
location in which it found the library, but that's just a cache, it doesn't
require the library to
--- Comment #6 from ian at airs dot com 2007-02-22 16:00 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2007-02-22 16:05 ---
Subject: Bug 17002
Author: jakub
Date: Thu Feb 22 16:04:55 2007
New Revision: 19
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=19
Log:
libjava/
PR libgcj/17002
PR classpath/28550
--- Comment #3 from marc dot glisse at normalesup dot org 2007-02-22 16:20
---
Actually, the patch is not sufficient. With the patch, it works if the function
is in the global namespace or the pragma is before the declaration (or both),
but not for a function in the std namespace where
trying to build cvs glibc as per instructions at cross-lfs.org's sysroot
branch.
with recent versions of mainline trunk(statically linked, no threads build) i
get build errors like:
../sysdeps/ieee754/dbl-64/s_signbit.c:27: error: redefinition of '__signbit'
--- Comment #2 from bonzini at gnu dot org 2007-02-22 16:46 ---
Changing the patch address since part 1 was approved. And adding bug 30907
since committing part 2 would cause that bug to surface on mainline.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #4 from bonzini at gnu dot org 2007-02-22 16:48 ---
Though we don't have a testcase for mainline, the bug is there too.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-22 17:04 ---
Can you walk me through some of the checks and why they can be removed? I see
(.004.gimple dump):
source = source_first;
target = target_first;
source_last.0 = (js__TsB) source_last;
source_first.1
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Keywords||build
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-22 17:21 ---
There is also code in build_common_tree_nodes_2 which needs changed to use
build_complex_type which also could be causing issues too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-22 17:29 ---
__signbit is not a macro so it cannot be undefined.
Also this is because extern inline changed meaning for -std=c99/-std=gnu99 to
be the C99 meaning instead of what GNU C decided it ment.
You need to use a newer
If a nested subroutine calls another nested subroutine that follows it
lexically, then convert_all_function_calls will force the called function to
take a static chain even though it may not need one. The most trivial example
of this is a recursive nested subroutine, as in example n1.c:
void
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-02-22 17:33
---
Do not work too hard on this, there is code in the AdaCore tree to disable
VRP in more cases, lest language-mandated checks are erroneously removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-02-22 17:40
---
Try this: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01201.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-02-22 17:41
---
Bonus points if you can reduce this to a C test case ;-)
Starting with the gimple dumps, this is usually not hard to do.
It can't be reduced because it relies on integer types with restricted ranges,
i.e.
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-02-22 18:00
---
Do not work too hard on this, there is code in the AdaCore tree to disable
VRP in more cases, lest language-mandated checks are erroneously removed.
For example PR ada/26797.
--
ebotcazou at gcc dot gnu
--- Comment #5 from rth at gcc dot gnu dot org 2007-02-22 18:07 ---
I don't think this has anything to do with either vectorization or my patch.
I was seeing that same failure with --with-arch=pentium4 before my patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
--- Comment #8 from baldrick at gcc dot gnu dot org 2007-02-22 18:14
---
Can you walk me through some of the checks and why they can be removed? I see
(.004.gimple dump):
...
I assume all of the above is gimplified from just
if Source_Last Source_First then
if
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-02-22 18:18
---
(In reply to comment #7)
Do not work too hard on this, there is code in the AdaCore tree to disable
VRP in more cases, lest language-mandated checks are erroneously removed.
For example PR ada/26797.
That
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-02-22 18:19
---
Please do not overwrite changes, thanks.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Headers like cwchar add overloads to libc functions. Here I am interested in
the functions for which the standard C version takes a const pointer and
returns a non-const pointer and in C++ this version is replaced by one with
const everywhere and one with no const anywhere. For this, in c_std
--- Comment #3 from sdirkse at gams dot com 2007-02-22 18:52 ---
I took out the restriction in resolve.c that leads to the error message, and it
does give me a clean compile, but the code does not do what I expect. For
example, passing a real(kind=8) by-value to C doesn't get me a good
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-22 19:04 ---
Reduced testcase:
struct QString { ~QString(); };
template class T struct QValueListNode {
QValueListNodeT* next;
T data;
};
template class T struct QValueListPrivate
{
~QValueListPrivate()
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-22 19:24 ---
(In reply to comment #3)
Enough facts, now for some ignorant speculation: I suppose there is some logic
missing to pass a value from the caller when the size of the value is not the
default size (i.e. 4 for my
--- Comment #5 from pcarlini at suse dot de 2007-02-22 19:29 ---
Now that we have a resolution for DR 526:
http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#526
we can fix this problem too, similarly to like libstdc++/17012.
--
pcarlini at suse dot de
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #8 from simartin at gcc dot gnu dot org 2007-02-22 19:58
---
Subject: Bug 29475
Author: simartin
Date: Thu Feb 22 19:57:55 2007
New Revision: 122236
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122236
Log:
2007-02-22 Simon Martin [EMAIL PROTECTED]
PR
--- Comment #9 from simartin at gcc dot gnu dot org 2007-02-22 20:09
---
Fixed on 4.2 as well.
I will not apply it on 4.1 as requested by Mark here:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01781.html
--
simartin at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pluto at agmk dot net 2007-02-22 20:23 ---
fixed for = 4.2
wontfix for 4.2 ( too big impact for mature branches ).
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-22 20:36 ---
(In reply to comment #6)
Created an attachment (id=12987)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12987action=view) [edit]
This fixes the PR
This is just now regtesting - I am pretty sure that it is
--- Comment #5 from patchapp at dberlin dot org 2007-02-22 21:10 ---
Subject: Bug number PR30887
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01839.html
--
Example:
...testsuite/gfortran.dg gfortran -c -pedantic-errors c_by_val_4.f ; echo $?
c_by_val_4.f:14.22:
CALL DOIT( %VAL( P ) ) ! { dg-warning Extension: argument list fu
1
Warnung: Extension: argument list function at (1)
c_by_val_4.f:16.22:
CALL DOIT( %VAL( P
--- Comment #6 from sdirkse at gams dot com 2007-02-22 21:35 ---
(In reply to comment #4)
(In reply to comment #3)
Enough facts, now for some ignorant speculation: I suppose there is some
logic
missing to pass a value from the caller when the size of the value is not
the
While trying to make DECL_GIMPLE_REG_P more generic, I ran into a regression
due to we never change non gimple register variables into gimple registers so I
looked into it and found that I could also reproduce it in the current sources
with vector types (complex does not matter as much as they are
--- Comment #9 from patchapp at dberlin dot org 2007-02-22 22:10 ---
Subject: Bug number PR30660
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01848.html
--
The simple test which I'll attach shortly, loops infinitely when compiled with
-O1 -fstrength-reduce and executes fine with plain -O1. Doing a little
debugging, it seems the loop index variable i is not incremented within the
loop causing us to loop forever.
I have tested this using the latest
--- Comment #1 from bergner at gcc dot gnu dot org 2007-02-22 22:40 ---
Created an attachment (id=13092)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13092action=view)
Reduced testcase showing the infinite looping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-02-22 22:54
---
Please do not overwrite changes, thanks.
Sorry about that - it wasn't on purpose: your comment
and mine collided. I actually checked the two bugs
after getting the message that I'd manage to wipe out
your
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
A meta-bug for PRs about fortran intrinsics.
--
Summary: [meta-bug] fortran intrinsics
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority: P3
Component: fortran
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-22 23:26 ---
I cannot reproduce this.
Please paste the output of gcc -v.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-22 23:29 ---
it only fails using the 4.1 compiler.
Well that is because loop.c has been removed in 4.2 and above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
--- Comment #4 from bergner at gcc dot gnu dot org 2007-02-22 23:32 ---
This is using source checked out this afternoon (revision 122219):
bg47:bergner% ./install/gcc-4.1/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc-4_1-20070222/configure
CALL exit(status=i)
The documented argument name status is rejected (but count is allowed):
gcc/fortran/intrinsic.c:2458-2460:
add_sym_1s (exit, 0, BT_UNKNOWN, 0, GFC_STD_GNU,
gfc_check_exit, NULL, gfc_resolve_exit,
c, BT_INTEGER, di, OPTIONAL);
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-22 23:37 ---
Hmm, ?: is a lvalue in C++. Since m_a is still an lvalue (a non modifiable one
though) we try to use operator short so we get the same type, const short,
on both sides of the : as short is a closer match to const
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-02-22 23:40 ---
Created an attachment (id=13093)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13093action=view)
testcase (dg-do compile)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-22 23:40 ---
Created an attachment (id=13094)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13094action=view)
testcase (dg-do link)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-22 23:43 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-22 23:45 ---
The second part of this bug is recorded as PR 22156.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30913
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|bootstrap |libstdc++
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-22 23:54 ---
How did you configure GCC?
Can you try building in a different directory from the source directory?
Also make sure you have read http://gcc.gnu.org/install/ .
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-22 23:58 ---
This is a bug in libstdc++ which was fixed in 4.2.0.
But note the code uses -fvisibility-inlines-hidden -fvisibility=hidden
without testing if the system library has been fixed. It only checks if those
options
--- Comment #102 from pinskia at gcc dot gnu dot org 2007-02-22 23:58
---
*** Bug 30900 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-23 00:01 ---
*** This bug has been marked as a duplicate of 30889 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-23 00:01 ---
*** Bug 30828 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30889
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-23 00:03 ---
This is a precompiled GCC which means we don't support this. What is happening
is that somene compiled it for their OS (which has a new symbol) and then
copied it to your machine and now it does not work.
--
--- Comment #30 from pinskia at gcc dot gnu dot org 2007-02-23 00:07
---
I think this is really a duplicate of bug 30509 which has a nice short
testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-23 00:07 ---
I think this is really a duplicate of bug 30509 which has a nice short
testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-23 00:10 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-23 00:11 ---
--enable-bootstrap
Don't use that option for 4.1.x.
Can you try again without that option?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-02-23 00:21 ---
A note on the testcase: gfortran seems to resolve EXIT only once.
If
CALL exit()
CALL exit(int_1)
gfortran happily compiles and links.
If
CALL exit(int_1)
CALL exit()
then
/tmp/ccuE9OGi.o: In function
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-02-23 00:38 ---
The documentation states:
Arguments:
STATUS The type of the argument shall be INTEGER(*).
but arguments of kind INTEGER(kind=1) and INTEGER(kind=2) may lead to
unresolved symbols (see also comment #3).
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Summary|current mainline fails to |[4.3
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-23 00:43 ---
*** This bug has been marked as a duplicate of 30825 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-23 00:43 ---
*** Bug 30921 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-02-23 01:59 ---
Frankly, I have no idea what to do with this... Certainly lately we have got
plenty of succesful builds on x86_64-linux and other linux platforms (just look
to testresults). Something mysterious is going on during the
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-02-23 05:43
---
Subject: Bug 30910
Author: jvdelisle
Date: Fri Feb 23 05:43:16 2007
New Revision: 122250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122250
Log:
2007-02-22 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-23 05:50
---
Sorry about that - it wasn't on purpose: your comment
and mine collided. I actually checked the two bugs
after getting the message that I'd manage to wipe out
your change, and the relationship between 26797
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-02-23 06:29
---
Subject: Bug 30910
Author: jvdelisle
Date: Fri Feb 23 06:29:03 2007
New Revision: 122251
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122251
Log:
2007-02-22 Jerry DeLisle [EMAIL PROTECTED]
PR
1 - 100 of 102 matches
Mail list logo
