--- Comment #33 from potswa at mac dot com 2010-09-11 04:56 ---
Note, I am not attempting to tell after write with a nontrivial codecvt
installed. Maybe the issue of Comment #5 is only in the general case?
I suppose it leaves UTF-8 files still a bit slow, but I still think that's
pretty
--- Comment #11 from hp at gcc dot gnu dot org 2010-09-11 04:56 ---
Corrected component re: analysis.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
C
--- Comment #32 from potswa at mac dot com 2010-09-11 04:49 ---
(In reply to comment #31)
> I'm afraid that the situation I outlined in Comment #5 is just the simple one.
> The real problem with the new scheme - which tries to deal specially with (0,
> cur) by not moving the file pointer
--- Comment #8 from hp at gcc dot gnu dot org 2010-09-11 04:33 ---
(In reply to comment #5)
> This regression disappeared in the range (162414:162421], perhaps because of
> r162418. Let's see if it remains hidden, or if this PR just shapeshifted into
> PR45051.
I (finally) checked this
--- Comment #31 from paolo dot carlini at oracle dot com 2010-09-11 04:27
---
I'm afraid that the situation I outlined in Comment #5 is just the simple one.
The real problem with the new scheme - which tries to deal specially with (0,
cur) by not moving the file pointer - is when *write
--- Comment #2 from rmansfield at qnx dot com 2010-09-11 04:13 ---
*** Bug 45627 has been marked as a duplicate of this bug. ***
--
rmansfield at qnx dot com changed:
What|Removed |Added
-
--- Comment #2 from rmansfield at qnx dot com 2010-09-11 04:13 ---
Introduced in rev164050 and fixed in rev164163. Fixed under PR45630.
*** This bug has been marked as a duplicate of 45630 ***
--
rmansfield at qnx dot com changed:
What|Removed |Ad
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-09-11
03:15 ---
This failure exists at r163743 with the addition of the
g++.dg/tree-prof/partition2.C testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45646
/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100910/gcc/testsuite/g++.dg/tree-prof/partition2.C
-nostdinc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/libstdc++-v3/include/x86_64-apple-darwin10.5.0
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-09-11
01:55 ---
Created an attachment (id=21774)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21774&action=view)
object file for g++.dg/tree-prof/partition2.C compiled as partition2.x52
--
http://gcc.gnu.org/bu
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-09-11
01:55 ---
Created an attachment (id=21773)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21773&action=view)
assembly file for g++.dg/tree-prof/partition2.C compiled as partition2.x52
--
http://gcc.gnu.org/
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-09-11
01:54 ---
Created an attachment (id=21772)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21772&action=view)
preprocessed source for g++.dg/tree-prof/partition2.C compiled as
partition2.x52
--
http://gcc.gn
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-09-11
01:53 ---
Created an attachment (id=21771)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21771&action=view)
partition2.gcda generated from partition2.x51 at -m64 on x86_64-apple-darwin10
--
http://gcc.gnu.
/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100910/gcc/testsuite/g++.dg/tree-prof/partition2.C
-nostdinc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/libstdc++-v3/include/x86_64-apple-darwin10.5.0
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple
d/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100910/gcc/testsuite/g++.dg/torture/pr44972.C
-nostdinc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_6
.C -O2 -fwhopr (test for excess errors)
The failures are of the form...
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100910/gcc/testsuite/g
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-11 00:23 ---
It also failed with
-DSPEC_CPU -DNDEBUG -O2 -ffast-math -DSPEC_CPU_LP64 -fno-strict-aliasing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45644
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-11 00:20 ---
It is caused by revision 164135:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00427.html
I got
*** glibc detected *** ../run_base_test_lnx32e-gcc./soplex_base.lnx32e-gcc:
double free or corruption (out): 0x000
--- Comment #27 from aoliva at gcc dot gnu dot org 2010-09-10 23:16 ---
> Shouldn't we do something else when hashing PRE_MODIFY?
I don't know, what else do you have in mind?
I'm posting an updated patch that implements your other suggestions
momentarily.
--
http://gcc.gnu.org/bug
On Linux/x86-64, revision 164143 miscompiled 450.soplex in SPEC CPU 2006:
Running 450.soplex ref peak lnx32e-gcc default
450.soplex: copy 0 non-zero return code (exit code=0, signal=11)
I used "-DSPEC_CPU -DNDEBUG -O3 -funroll-loops -ffast-math -DSPEC_CPU_LP64
-fno-strict-aliasing".
--
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2010-09-10 21:40
---
*** This bug has been marked as a duplicate of 31519 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2010-09-10 21:40
---
*** Bug 45575 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-09-10 21:26
---
Two more things:
1. there's no need for __int128, the following code also triggers it:
unsigned foo (unsigned char i) { return __builtin_popcountl ((unsigned long)
i); }
2. On x86_64-darwin, the code above fa
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-09-10 21:24
---
Confirmed on x86_64-linux, with the following C source:
unsigned foo (__int128 i)
{
return __builtin_popcountl ((unsigned long) i);
}
$ ./gcc/cc1 -ftree-ter a.c -quiet
a.c: In function foo:
a.c:3:30: intern
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2010-09-10 21:08
---
Closing, please reopen with additional information if the problem persists with
a more recent version of the compiler (>= 4.5.0). Thanks!
--
fxcoudert at gcc dot gnu dot org changed:
What|Remov
--- Comment #30 from potswa at mac dot com 2010-09-10 20:33 ---
(In reply to comment #29)
> And, please, if you want to help, manage to run the testsuite, we have got
> some
> pretty nasty testcases ;)
I'll see if I can compile the latest⦠guess it's more useless to have an old
tree
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #29 from paolo dot carlini at oracle dot com 2010-09-10 19:51
---
And, please, if you want to help, manage to run the testsuite, we have got some
pretty nasty testcases ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #28 from paolo dot carlini at oracle dot com 2010-09-10 19:34
---
PS: you are right that we have to check that _M_seek succeeds before adding
back __computed_off.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #27 from paolo dot carlini at oracle dot com 2010-09-10 19:31
---
Note that certainly we don't want to use C++0x stuff here. Also, one thing at a
time of course, thus if we have been missing some error checking, etc, it's for
another time.
--
http://gcc.gnu.org/bugzilla
--- Comment #26 from potswa at mac dot com 2010-09-10 19:30 ---
(In reply to comment #25)
> Created an attachment (id=21769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21769&action=view) [edit]
> alternative approach. untested
>
> I hope this compiles ;v) . But it seems to "col
--- Comment #25 from potswa at mac dot com 2010-09-10 19:26 ---
Created an attachment (id=21769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21769&action=view)
alternative approach. untested
I hope this compiles ;v) . But it seems to "color within the lines."
Why does your patc
--- Comment #10 from joachim dot reichel at gmx dot de 2010-09-10 19:17
---
Any chance to get that committed for the 4.4.5 RC?
See http://gcc.gnu.org/ml/gcc/2010-09/msg00146.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44919
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10
19:10 ---
Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris
2/SPARC
>> > So please attach a testcase (easiest is probably in a non-bootstrapped
>> > tree run make check and pick a simple
--- Comment #24 from paolo dot carlini at oracle dot com 2010-09-10 19:01
---
Created an attachment (id=21768)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21768&action=view)
Draft
This is what I have so far, unfortunately I cannot work only on this today.
Anyway, it passes test
--- Comment #23 from potswa at mac dot com 2010-09-10 18:53 ---
(In reply to comment #22)
> Good. Then I have a draft almost ready ;)
I have a very straightforward, low-impact solution, but I haven't tested it.
(My tree is pretty out of date.) Would you like to try it, if you're having
--- Comment #4 from hjl dot tools at gmail dot com 2010-09-10 18:41 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #6 from jason at gcc dot gnu dot org 2010-09-10 18:29 ---
Subject: Bug 43824
Author: jason
Date: Fri Sep 10 18:28:59 2010
New Revision: 164201
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164201
Log:
PR c++/43824
* error.c (maybe_warn_cpp0x): Add ne
"pragma GCC optimize" or function __attribute__'s can be used
to request specific optimization levels or "-f" type command
line arguments.
I would like to be able to turn off debugging symbols
as well. The equivalent of the "-g0" command line option.
It might be useful to be able to selectively tu
--- Comment #4 from tbptbp at gmail dot com 2010-09-10 18:00 ---
(In reply to comment #2)
> I think you need __attribute((aligned(16))) on the original forward declared
> class too.
As stated that does, indeed, fix it.
So, ok, let's say previous versions were too permissive, then, the pr
--- Comment #22 from paolo dot carlini at oracle dot com 2010-09-10 17:42
---
Good. Then I have a draft almost ready ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #21 from potswa at mac dot com 2010-09-10 17:40 ---
(In reply to comment #18)
> I'm almost ready for the patch, please be patient ;) If look at the standard,
> it says that the last step of seekoff is *always* as if calling fseek(..., off
> * width, ...). If look at the curre
--- Comment #20 from potswa at mac dot com 2010-09-10 17:35 ---
(In reply to comment #17)
> The task is to call fseek(0,cur), and then subtract the number of bytes in the
> put area plus the "external characters," right?
Er, I don't mean "bytes in the put area" exactly, but you know wh
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 17:35 ---
This seems related to PR 45112.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-10 17:34 ---
I think you need __attribute((aligned(16))) on the original forward declared
class too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
away.
I've failed to reduce both manually and with delta (mismatched prototypes are
too easily produced). Sorry.
$ /usr/local/gcc-4.6-20100910/bin/g++ -std=c++0x -c synth.ii
src/audio/synth_voice_impl.h:140:6: error: prototype for 'bool
synth::voice::voice_t::produce_chunk(c
--- Comment #1 from tbptbp at gmail dot com 2010-09-10 17:34 ---
Created an attachment (id=21767)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21767&action=view)
large & fugly testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #19 from paolo dot carlini at oracle dot com 2010-09-10 17:30
---
Of course here I'm always under the assumption width > 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #18 from paolo dot carlini at oracle dot com 2010-09-10 17:29
---
I'm almost ready for the patch, please be patient ;) If look at the standard,
it says that the last step of seekoff is *always* as if calling fseek(..., off
* width, ...). If look at the current code, we have
--- Comment #17 from potswa at mac dot com 2010-09-10 17:25 ---
(In reply to comment #16)
> Actually, however, I don't think we can really always call fseek(off * width)
> as the Standard want us to do. In a sense I'm happy because the change is
> gonna
> be less invasive, on the other
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 17:20 ---
>libmpfr.so.1: undefined symbol: __gmp_get_memory_functions
That means libmpfr is finding the incorrect GMP. This is not a GCC bug but
rather a bug in your LD_LIBRARY_PATH or ld.so configuration.
--
pinskia at
Have problem to make fortran work in x64 environment.
Linux test1.us.icap.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-10 17:14 ---
Hi,
would be possible to have preprocessed source for a cross compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
--- Comment #16 from paolo dot carlini at oracle dot com 2010-09-10 17:11
---
Actually, however, I don't think we can really always call fseek(off * width)
as the Standard want us to do. In a sense I'm happy because the change is gonna
be less invasive, on the other hand I'm a bit puzzl
Compiler output:
$ gcc -mno-mmx -m3dnow -flto gcc.c-torture/execute/20050316-2.c
In file included from gcc.c-torture/execute/20050316-2.c:34:0,
from :0:
gcc.c-torture/execute/20050316-2.c: In function 'main':
gcc.c-torture/execute/20050316-2.c:45:15: internal compiler error: in
co
--- Comment #15 from potswa at mac dot com 2010-09-10 16:15 ---
(In reply to comment #14)
> (The result doesn't depend on
> the pointers, it comes from fseek.)
I re-read Comment 5 and understand it this time ;v) . Well, any solution should
fix both tellg and tellp, since the pointers a
--- Comment #8 from mikael at gcc dot gnu dot org 2010-09-10 16:11 ---
In the patch there is a small mistake :
+ if (symtree->n.sym->attr.flavor == FL_PARAMETER
+ && symtree->n.sym->attr.intent != INTENT_OUT)
+symtree->n.sym->points_to = &gfc_pt_dummy;
Parameters in the fortr
--- Comment #5 from leftynm at umich dot edu 2010-09-10 16:06 ---
Thanks guys. Yeah, I guess my use of PARAMETER wasn't consistent with how it
works. I was using it to set a variable such that it cannot be changed. I
found a work around though lets me keep it as a PARAMETER, but allow
--- Comment #25 from paolo dot carlini at oracle dot com 2010-09-10 16:01
---
Good. Please give me a couple of days to come to your code. Note, since you
don't have a Copyright Assignment on file, it will be difficult to fully
acknowledge your work in the ChangeLog. Thus, I would sugges
--- Comment #14 from potswa at mac dot com 2010-09-10 15:59 ---
(In reply to comment #13)
> Good, I think we are close to a fix, I'm already testing something. So, do we
> have a symmetric issue with the put area or not? I'm not sure.
I believe so. tellg and tellp are both handled by se
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:59 ---
(In reply to comment #3)
> >For volatile fields we should use accesses of the appropriate width.
>
> The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC
> it
> says they sho
--- Comment #6 from rguenther at suse dot de 2010-09-10 15:51 ---
Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file
on Solaris 2/SPARC
On Fri, 10 Sep 2010, ro at CeBiTec dot Uni-Bielefeld dot DE wrote:
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10
15:48 ---
Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris
2/SPARC
> --- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27
> ---
> I don't have access to sparc-s
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-10 15:47 ---
For arbitrary lengths (both of the constant string and of the padding) the
memmove (which will be optimized to memcpy as the source is read-only) + memset
is the best thing to do, replacing say
memmove (x, "900 bytes l
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 15:46 ---
>For volatile fields we should use accesses of the appropriate width.
The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC it
says they should be doing the largest available (up to the regist
--- Comment #13 from paolo dot carlini at oracle dot com 2010-09-10 15:45
---
Good, I think we are close to a fix, I'm already testing something. So, do we
have a symmetric issue with the put area or not? I'm not sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:43 ---
(In reply to comment #1)
> >1. index is constant or variable, and
>
> Yes that is correct.
>
> >2. the 'bar' field type.
>
> The alignment of the access is different in those cases.
Sorry, the t
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-10 15:35 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from kargl at gcc dot gnu dot org 2010-09-10 15:34 ---
(In reply to comment #3)
> (In reply to comment #1)
> > I have a slightly different result with your code.
> >
> > troutmask:sgk[212] gfc4x -c -O g.f90
> > g.f90: In function 'rcrdrd':
> > g.f90:1:0: internal compiler
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-10 15:32 ---
(In reply to comment #1)
> I have a slightly different result with your code.
>
> troutmask:sgk[212] gfc4x -c -O g.f90
> g.f90: In function 'rcrdrd':
> g.f90:1:0: internal compiler error: in build_int_cst_wide, at t
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 15:30 ---
>1. index is constant or variable, and
Yes that is correct.
>2. the 'bar' field type.
The alignment of the access is different in those cases.
>In any case byte accesses should be used.
Why, word access is ju
cd rts; ../../xgcc -B../../ -shared -g -O2 \
-fPIC -frandom-seed=fixed-seed \
-o libgnat-4.6.sl \
a-assert.o a-calari.o a-calcon.o a-caldel.o a-calend.o
a-calfor.
o a-catizo.o a-cdlili.o a-cgaaso.o a-cgarso.o a-cgcaso.o a-chacon.o a-chahan.o
a
-chara
--- Comment #24 from tstarling at wikimedia dot org 2010-09-10 15:25
---
Created an attachment (id=21766)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21766&action=view)
dynamic_cast<> hack
The attached patch uses a dynamic_cast<> hack to avoid the need to break the
ABI. I added
/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk/configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/
Thread model: posix
gcc version 4.6.0 20100910 (experimental)
--- Comment #12 from don dot wakefield at gmail dot com 2010-09-10 15:24
---
(In reply to comment #11)
> Sure. What I meant - contrary to wait you said, I think - is that an elegant
> and complete solution to this issue involves changing much more generally our
> code to *always* behave
--- Comment #2 from kargl at gcc dot gnu dot org 2010-09-10 15:20 ---
The -fdump-tree-original for HJ's original code look like
rcrdrd (character(kind=1)[1:4] & restrict vtyp, integer(kind=4) _vtyp)
{
static character(kind=1) dbl[1:1] = "D";
(MEM[(c_char * {ref-all})vtyp] = MEM[(c_
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-10 15:19
---
Sure. What I meant - contrary to wait you said, I think - is that an elegant
and complete solution to this issue involves changing much more generally our
code to *always* behave as if fseek(off * width) were
--- Comment #4 from ro at gcc dot gnu dot org 2010-09-10 15:19 ---
Jan, could you please have a look.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10
15:15 ---
Subject: Re: [4.6 regression] Reference to undefined label building libada no
Solaris 2/SPARC
A reghunt identified that the regression was caused by this patch:
2010-09-07 Jan Hubicka
* tree-i
--- Comment #10 from don dot wakefield at gmail dot com 2010-09-10 15:15
---
(In reply to comment #9)
> Ok. I don't think we should change the code to deal such specially with off ==
> 0, if we are going to change it we should decouple the return value from what
> the underlying seek re
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-10 15:12 ---
I have a slightly different result with your code.
troutmask:sgk[212] gfc4x -c -O g.f90
g.f90: In function 'rcrdrd':
g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218
Please submit a full bug r
Please have a look at this test case:
#include
struct type1 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;
} foo [1];
uint8_t bar;
};
volatile struct type
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-10 15:00
---
Ok. I don't think we should change the code to deal such specially with off ==
0, if we are going to change it we should decouple the return value from what
the underlying seek returns, and always call fseek(..
--- Comment #8 from don dot wakefield at gmail dot com 2010-09-10 14:54
---
Paolo, yes, _M_file.seekoff(0,cur) would return the current physical file
position, and then filebuf::seekoff would adjust the returned pos_type to
reflect the position within the *logical* file, framed by the b
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-10 14:52 ---
It may be caused by revision 164148:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00440.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
.cfi_endproc
.LFE0:
.size rcrdrd_, .-rcrdrd_
.section.rodata
.type dbl.1557, @object
.size dbl.1557, 1
dbl.1557:
.ascii "D"
.ident "GCC: (GNU) 4.6.0 20100910 (experimental)"
.section.note.GNU-stack,&q
--- Comment #3 from hjl at gcc dot gnu dot org 2010-09-10 14:44 ---
Subject: Bug 45634
Author: hjl
Date: Fri Sep 10 14:44:20 2010
New Revision: 164183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164183
Log:
Check that result of string folding is of integral type.
gcc/
2010-
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-10 14:40 ---
For the interprocedural analysis I believe static points-to is the only
reasonable thing to do, anything else would have too big complexity (both space
and time). Within one function, sure, you have the code, but not
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-10 14:39
---
Then, seekoff would also return a position beyond the buffer, right? Or you
want it to return 1 anyway? Actually, I think the standard want us to use width
* off for the underlying fseek anyway, not only for of
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-10 14:39 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00951.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-10 14:38 ---
Fixed for 4.6.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|U
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-10 14:22 ---
Subject: Bug 44115
Author: rguenth
Date: Fri Sep 10 14:22:22 2010
New Revision: 164179
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164179
Log:
2010-09-10 Richard Guenther
PR debug/44115
On Linux/ia64, revision 164164 gave
../../../../src-trunk/libstdc++-v3/libsupc++/array_type_info.cc:33:1: internal
compiler error: tree check: expected tree that contains 'decl with RTL'
structure, have 'addr_expr' in output_constant, at varasm.c:4408
Please submit a full bug report,
with preproce
--- Comment #6 from don dot wakefield at gmail dot com 2010-09-10 14:06
---
Re: comment 5 - what is needed is for filebuf::seekoff(0,ios::cur) to:
1) *not* invalidate the buffer
2) *not* move the file pointer
since all that special case asks is "where am I in the 'logical' file?"
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-10 13:39 ---
[...@gnu-16 0001]$ cat pr45634.f90
SUBROUTINE RCRDRD (VTYP)
CHARACTER(4), INTENT(OUT) :: VTYP
CHARACTER(1), SAVE :: DBL = "D"
VTYP = DBL
END
[...@gnu-16 0001]$ /export/gnu/impo
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-10 13:26 ---
(In reply to comment #6)
> (In reply to comment #5)
> > I see before SLP:
> >
> > :
> > MEM[(struct A *)this_1(D)].a = 0;
> > MEM[(struct A *)this_1(D)].b = 0;
> > MEM[(struct A *)this_1(D)].c = 0;
> > [LP 2
1 - 100 of 142 matches
Mail list logo
