The current implementation of begin() for unordered associative containers is
linear (a search for the first non-empty bucket is executed each time begin()
is called), yet the C++0x drafts specifiy that this should be constant (23.3.1,
table 93). Boost.Unordered, for instance, caches the first
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-06-09 13:39 ---
The following patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
should fix the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44453
--- Comment #14 from andi-gcc at firstfloor dot org 2010-06-09 13:42
---
I found this code in lto.c which seems to disagree:
/* Read the options saved from each file in the command line. Called
from lang_hooks.post_options which is called by process_options
right before all the
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-06-09 13:43 ---
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.
Honza
--
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 13:50 ---
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.
It does fix the bootstrap failure. I am currently
--- Comment #42 from gcc at breakpoint dot cc 2010-06-09 13:52 ---
(In reply to comment #41)
The ICE in #38 is due to a bug in caller-save.c
Thank you for the very quick fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #15 from andi-gcc at firstfloor dot org 2010-06-09 13:55
---
Ok seems it does not do what I want:
FIXME lto. Currently the scheme is limited in that only the
options saved on the first object file (f1.o) are read back during
the link step. This means that the
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-09 13:55 ---
There are more issues:
1) cleanup_barriers seems to do weird things with these empty bbs from
__builtin_unreachable (), I guess it shouldn't reorder anything if prev is a
LABEL_P
2) the reason why this compiles fine
When compiling the following program with -O2, gcc gives an ICE internal
compiler error: in trunc_int_for_mode, at explow.c:56.
Versions affected:
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
gcc (GCC) 4.5.1 20100521 (prerelease)
static inline
--- Comment #7 from paolo at gcc dot gnu dot org 2010-06-09 14:02 ---
Subject: Bug 44413
Author: paolo
Date: Wed Jun 9 14:02:03 2010
New Revision: 160476
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160476
Log:
2010-06-09 Paolo Carlini paolo.carl...@oracle.com
--- Comment #43 from mark dot workman at acm dot org 2010-06-09 14:07
---
(In reply to comment #39)
Hi, Kyle Moffett,
in testall.c, r9 is used by a register variable, however, in E500ABI
guide,
r9 should be used for parameter passing, this test case seems not reasonable.
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-09 14:13 ---
(In reply to comment #4)
(In reply to comment #1)
It may be broken by revision 160394:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
The add-lea transformation doesn't even trigger in this
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 14:15 ---
Subject: Bug 44211
Author: janus
Date: Wed Jun 9 14:14:08 2010
New Revision: 160478
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160478
Log:
2010-06-09 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #12 from bergner at gcc dot gnu dot org 2010-06-09 14:15
---
Subject: Bug 44067
Author: bergner
Date: Wed Jun 9 14:15:11 2010
New Revision: 160479
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160479
Log:
Backport from mainline:
2010-06-09 Edmar
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-09 14:16 ---
Fixed with r160478. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-09 14:16 ---
Whatever we do, we need to preserve Atom add-lea optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
manu at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org writes:
I find this output a bit confusing. I find clang's output clearer
http://clang.llvm.org/diagnostics.html.
I guess you are talking about the automatic macro expansion section of
that link?
In fact, clang's output actually follows
--- Comment #27 from dodji at gcc dot gnu dot org 2010-06-09 14:23 ---
Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL
constants
manu at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org writes:
I find this output a bit confusing. I find clang's output clearer
manu at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org writes:
$ ./cc1 -quiet test.c
While expanding macro OPERATE at test.c:2:8
While expanding macro SHIFTL at test.c:5:14
While expanding macro MULT2 at test.c:8:3
test.c: In function 'g':
test.c:13:3: error: invalid operands to binary
--- Comment #28 from dodji at gcc dot gnu dot org 2010-06-09 14:32 ---
Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL
constants
manu at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org writes:
$ ./cc1 -quiet test.c
While expanding macro OPERATE at test.c:2:8
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-06-09 14:43
---
OK, I have found the bug and I admit it is rather embarrassing. I'll
submit a patch soon.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-09 15:07 ---
With the patch for PR 44211 (just committed to the 4.6 trunk), the program
compiles and the output is:
shape
In generic_shape_assign
x = 10
y = 20
circle
In generic_shape_assign
x =
--- Comment #9 from jason at gcc dot gnu dot org 2010-06-09 15:12 ---
Subject: Bug 44366
Author: jason
Date: Wed Jun 9 15:11:42 2010
New Revision: 160483
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160483
Log:
PR c++/44366
* g++.dg/cpp0x/decltype23.C: Move
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:13
---
I gave this more thought, and to be honest, focusing on 64-bit targets - I
think that for 32-bit targets what we have is already good enough - I have no
idea how to substantively improve the code, given that
--- Comment #6 from ian at rhymneyconsulting dot co dot uk 2010-06-09
15:20 ---
Subject: RE: [OOP] ICE with polymorphic object oriented example
Thanks very much for fixing it.
Cheers
Ian
-Original Message-
From: burnus at gcc dot gnu dot org
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
CC|mikestump at comcast dot net|
Target Milestone|--- |4.6.0
--- Comment #5 from paolo at gcc dot gnu dot org 2010-06-09 15:35 ---
Subject: Bug 44461
Author: paolo
Date: Wed Jun 9 15:34:45 2010
New Revision: 160488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160488
Log:
2010-06-09 Khem Raj raj.k...@gmail.com
PR
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-09 15:36
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 15:46
---
I see. Looks like Matt essentially followed in the reference implementation the
legacy HP / SGI, linear, way of computing begin(). I'm asking his opinion on
this, whether we are also going to use caching or
--- Comment #7 from raj dot khem at gmail dot com 2010-06-09 15:48 ---
thanks Paolo, we would need this patch on 4.5 branch as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:52
---
In general, only if it's a regression. And nobody said that explicitly so far.
If you want to argue for having it anyway in 4_5-branch, please speak on the
mailing list and ask permission to the release
note this is later bootstrap stages so shouldn't matter what the bootstrap
compiler was (assuming it compiled the compiler reasonably correctly)
For the missing prototypes, I suggest you just put them right there:
void Foo(void);
void Foo(void)
{
...
}
for the uninitialized I suggest just
--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-09 16:36 ---
cross-ref:
http://sourceware.org/bugzilla/show_bug.cgi?id=5780
http://sourceware.org/bugzilla/show_bug.cgi?id=5784
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-09 16:39 ---
Patch has been committed to 4.4, 4.5, and trunk.
Closing.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 16:56 ---
It is caused by revision 142799:
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00498.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-09 17:05
---
Thanks HJ.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
--- Comment #29 from dodji at gcc dot gnu dot org 2010-06-09 17:09 ---
Created an attachment (id=20878)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878action=view)
Refreshed version. Fully Bootstraps the C FE and passes regression tests.
This fixes a annoying bug that were
--- Comment #11 from mrs at gcc dot gnu dot org 2010-06-09 17:21 ---
Fixed.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-09 17:24 ---
Can be reproduced also with
c++filt
_ZN5boost6tuples5tupleIN23abcdefgxyzzzabb3AaaENS2_4klmn16BaaaENS0_9null_typeES6_S6_S6_S6_S6_S6_S6_EE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
--- Comment #5 from jay dot krell at cornell dot edu 2010-06-09 17:39
---
Exact same errors building gc (not gcc) using gcc 4.3.5 on OSF/1 5.1.
I haven't tried building java/libjava. Will probably do that.
Please reopen.
make[2]: Entering directory `/home/jayk/obj/gc'
gcc
--prefix=/afs/mpa/data/martin/ugcc
--with-ppl=/afs/mpa/data/martin/numlibs64
--with-cloog=/afs/mpa/data/martin/numlibs64
--with-libelf=/afs/mpa/data/martin/numlibs64 --enable-languages=c++,fortran
--enable-target=all --enable-checking=release
Thread model: posix
gcc version 4.6.0 20100609 (experimental
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-06-09 17:42
---
Created an attachment (id=20879)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20879action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
--- Comment #7 from hp at gcc dot gnu dot org 2010-06-09 17:53 ---
(In reply to comment #5)
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.
When applied to r160481, it
--- Comment #30 from manu at gcc dot gnu dot org 2010-06-09 17:57 ---
(In reply to comment #29)
Created an attachment (id=20878)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878action=view) [edit]
Refreshed version. Fully Bootstraps the C FE and passes regression tests.
--- Comment #12 from jakub at gcc dot gnu dot org 2010-06-09 18:09 ---
I see the bug.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-09 18:38 ---
Subject: Bug 44430
Author: janus
Date: Wed Jun 9 18:38:11 2010
New Revision: 160504
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160504
Log:
2010-06-09 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-09 18:39 ---
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.
It does fix the bootstrap failure. I am currently
--- Comment #2 from falk at debian dot org 2010-06-09 19:11 ---
Confirmed, seems to be in if-conv. Here's a smaller test case:
int ffesum (void) {
int ch[4], ii, jj, kk;
char asc[32];
for (ii = 0; ii 4; ii++)
{
for (jj = 0; jj 4; jj++)
ch[jj] = ii;
for
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-09
19:19 ---
Subject: Re: bunch of warnings of second definition on osf
I've regularly seen those warnings, but ignored them since I've found no
ill effect and the testsuite largely passes (which doesn't use the
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-06-09 19:24
---
As I read this, the test case is invalid since it does not have a rewind or
backspace before the write?
If we want to change this to be an intended extension, I suppose we should
issue a warning or error for
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:41 ---
Subject: Bug 44359
Author: dfranke
Date: Wed Jun 9 19:40:58 2010
New Revision: 160505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160505
Log:
gcc/fortran/:
2010-06-09 Daniel Franke
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-09 19:41 ---
(In reply to comment #1)
As I read this, the test case is invalid since it does not have a rewind or
backspace before the write?
Yes - I expect that gfortran should issue an EOR error instead of happily
accepting
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-09 19:42 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:45 ---
I believe this is a dupe of PR33341.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-09 20:11 ---
Confirmed.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from joseph at codesourcery dot com 2010-06-09 20:14 ---
Subject: Re: iterators already defined for std::vector when
using std::decimal
On Wed, 9 Jun 2010, paolo dot carlini at oracle dot com wrote:
Janis, this doesn't make sense to me, and for sure happens only with
--- Comment #9 from bernds at gcc dot gnu dot org 2010-06-09 20:20 ---
Created an attachment (id=20880)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20880action=view)
A new version of Jim's patch
Here's what I've done with it so far. I've changed the new tree code to be a
proper
--- Comment #1 from eric dot weddington at atmel dot com 2010-06-09 20:21
---
This is not a bug.
Please see the avr-libc documentation for avr/wdt.h here:
http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html
which gives the method to disable the watchdog.
--
eric
Between gcc-4.6-20100529 and gcc-4.6-20100605 a number of new testsuite FAILs
appeared on sparc64-linux:
=== gfortran tests ===
FAIL: gfortran.fortran-torture/execute/forall_7.f90 execution, -O2
-fomit-frame-pointer -finline-functions -funroll-loops
FAIL:
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 20:30 ---
(In reply to comment #6)
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
I am not sure this is correct. The code
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.6.0
--- Comment #2 from joaquin at tid dot es 2010-06-09 20:34 ---
Caching can also have undesired consequences: for additional context on the
problem, see
https://svn.boost.org/trac/boost/ticket/4264
Note that *two* problems are discussed there, one is LWG issue #579 and the
other the
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 20:57 ---
*** Bug 2 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-09 20:57 ---
(In reply to comment #2)
This is a known limitation of array constructors handling by gfortran.
I was about to ask if this pr is a duplicate. From comment #3, it is; so I am
closing it as such.
For the record the
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r160490-install
--program-prefix=r160490- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100609 (experimental) (GCC)
[reg...@gamow tmp414]$ current-gcc -c -O small.c
small.c: In function 'func_21
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 21:17 ---
Here's a quick shot at fixing the ICE:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160503)
+++ gcc/fortran/resolve.c
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-09 21:19 ---
This should work (untested). However, ASYNCHRONOUS is F2003. Should one
introduce standard-specific checks? The whole function seems to be agnostic in
this respect?!
Index: interface.c
The Sunnamed::f() text reads as though S were a template. I suspect the
text is simply missing a space between the S and unnamed but I wonder if
the unnamed bit could actually be replaced by something less ambiguous
in C++ (such as /* unnamed */ or perhaps better still, /* anonymous */).
Btw.,
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-06-09 21:36 ---
Subject: Bug 44347
Author: dfranke
Date: Wed Jun 9 21:36:33 2010
New Revision: 160506
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160506
Log:
gcc/fortran/:
2010-06-09 Daniel Franke
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-09 21:40 ---
It is caused by revision 160124:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00036.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-09 21:48
---
Oops, thanks Joseph.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-06-09 21:50
---
Subject: Bug 42461
Author: ebotcazou
Date: Wed Jun 9 21:49:44 2010
New Revision: 160507
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160507
Log:
PR rtl-optimization/42461
* dce.c
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-09 22:02 ---
I'm VERY much in favour of using something that is not valid C++ syntax, rather
than unnamed
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-09 22:06 ---
It is caused by revision 159886:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00942.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-06-09 22:10
---
Another one that fails:
subroutine func (x)
use demo
integer :: x
x = 999
end subroutine func
subroutine foo
interface
subroutine func(x)
integer :: x
end subroutine func
end interface
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2010-06-09 22:11
---
(In reply to comment #16)
Re-confirmed with current trunk, testcase from (comment #8).
I think it now passes.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from spop at gcc dot gnu dot org 2010-06-09 22:13 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #9 from paolo dot carlini at oracle dot com 2010-06-10 00:26
---
As far as we can see can't be substantively improved. See also the thread
starting at: http://gcc.gnu.org/ml/libstdc++/2010-06/msg00073.html
--
paolo dot carlini at oracle dot com changed:
What
This program doesn't compile with g++-4.5 -std=c++0x -c test.cpp
I'm using:
g++-4.5 (Debian 4.5.0-5) 4.5.1 20100602 (prerelease)
I also verified the same behavior on:
g++ (Debian 20100530-1) 4.6.0 20100530 (experimental) [trunk revision 160047]
#include utility
int x, y;
std::pairint ,int
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 00:43 ---
I think this is because C++0x introduces rvalue references and those cannot
bind to lvalues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-10 00:48 ---
What I mean is that the C++ front-end is correct to reject the code that
libstdc++ provides to it. If there is a bug it is a problem with libstdc++ (or
maybe even the in flux C++0x STL :) ).
--
to succeed:
Executing on host: /user/inria/fsf/bld-20100609/gcc/xgcc
-B/user/inria/fsf/bld-20100609/gcc/
/user/inria/fsf/gcc/gcc/testsuite/objc/compile/trivial.m -fnext-runtime
-B/user/inria/fsf/bld-20100609/i686-pc-linux-gnu/./libobjc/.libs
-L/user/inria/fsf/bld-20100609/i686-pc-linux-gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 01:04 ---
-fnext-runtime should fail on x86-linux-gnu anyways. Why it is not failing is
a good question. If this is failing without --enable-build-with-cxx there is
a bug somewhere.
--
pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-10 01:06 ---
On x86_64-linux-gnu it does the correct thing:
Executing on host: /home/pinskia/src/local/gcc/objdir/gcc/xgcc
-B/home/pinskia/src/local/gcc/objdir/gcc/
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-10 01:07
---
The constructor at issue is trivially conforming to the most recent specs
(n3092) (*), thus, in my opinion, either this is a compiler issue, or a defect
in c++0x or a feature in c++0x itself, can't be a
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
This one was posted at gfortran.org
program f90_test
implicit none
integer :: ii8,ii4
ii4=0
ii8=522405223
print'(z4)',ii4
print'(z12)',ii8
print *, z=, z'1000'
print *, transfer(ii8,z'1000')
print *, transfer(ii8,z'1000')
ii4=30292 !=z'7654'
print'(z4)',ii4
--- Comment #2 from bangerth at gmail dot com 2010-06-10 03:27 ---
This is a regression:
2.95: struct S {anonymous}::f()
3.4: S unnamed::f()
4.0: Sunnamed::f()
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2010-06-10 03:28 ---
Created an attachment (id=20881)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20881action=view)
patch
This patch fixes it for me. I'm not entirely sure this is a proper use of
forward, but it seems
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 04:24 ---
This is probably a bogus PR.
The BOZ literal constants are INTEGER(16) entities
(at least of x86_64). ii8 is an INTEGER(4) item.
The transfer() in the print statement is returning
a INTEGER(16) entity where only
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-06-10 04:37
---
Interesting!
print *, kind=, kind(transfer(ii4,z'1000'))
On my system this gives kind = 8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
Since x86 zero extends when passing argument,
we get memory mismatch stall:
[...@gnu-6 899]$ cat call-1.c
short
__attribute__((noinline))
foo (short x, short y, short z)
{
return x + y + z;
}
short
bar (short z, short x, short y)
{
return foo (x, y, z);
}
[...@gnu-6 899]$ gcc -O2 -m32
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-06-10 05:21
---
The result of transfer is largest kind of decimal. Can be kind=8 or kind=16
depending on the system. Maybe we should add some documentation in the manual
on this. Thanks Steve for pointing this out.
--
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-10 05:23 ---
This patch
---
iff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index a33d3af..6f569cc 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -820,7 +820,10 @@
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-10 05:41 ---
I see the same problem now with revision 160389.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
101 - 196 of 196 matches
Mail list logo
