On 11/27/05, Jonathan Wakely [EMAIL PROTECTED] wrote:
Yes, I know it's a wiki and I can do this myself, but I only have so
much spare time and maybe the second one was added for a good reason.
http://en.wikipedia.org/wiki/Be_bold
Works for them.
Alexander wrote:
Hello!
How I can know more about implementation at 'tree' level such
extension as 'typeof'? I am not want to explore and change sources
now, maybe someone cam help?
your two desires conflict. typeof is implemented in cp/rtti.c
nathan
--
Nathan Sidwell::
Hi,
At the moment, we have only one bug I consider release critical for 3.4.5.
middle-end/24804 Produces wrong code
This bugs was reported against 3.4.4; it is a bit odd because it is
wrong code generation with '-O3 -fno-strict-aliasing'.
Mark, RTH, could you provide hints?
I'm
On Sun, 2005-11-27 at 03:14, Mike Stump wrote:
On Nov 22, 2005, at 7:52 AM, Richard Earnshaw wrote:
3) A volatile load isn't moved across any store that may alias (though
I'd expect that to be volatile if there's a real risk of aliasning, so
maybe we could have another dimension in the
Richard Earnshaw wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.
Logic would suggest that
Hi!
There are several g*dg/compat/ tests failing that show ABI
incompatibilities:
FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_alt.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_alt.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t026
Hello,
when gcc emits vague linkage data for C++ like vtables it makes them all
weak. Is there some reason why this needs to be done?
If I'm getting it right, based on e.g. on the comment in binutils/bfd/elf.c
saying that they are weak in order to allow multiple copies and that the GNU
ld
Gabriel Dos Reis wrote:
Mark, RTH, could you provide hints?
I don't have any ideas, just from looking atthe problem. It could be a
stack allocation problem, where we assign two things the same stack
slot, and get confused.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
On Nov 28, 2005, at 3:00 AM, Richard Earnshaw wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
Logic would suggest that a program is unpredictable if written in
such a
way that permits such aliases
On Nov 28, 2005, at 3:13 AM, Robert Dewar wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.
On Nov 28, 2005, at 3:13 AM, Robert Dewar wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this
On Mon, Nov 28, 2005 at 04:10:55PM +0100, Lubos Lunak wrote:
when gcc emits vague linkage data for C++ like vtables it makes them all
weak. Is there some reason why this needs to be done?
In the case of vtables, they are only weak if all the virtual functions
are defined as inline. Otherwise
On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
What is GNU C if it is not well documented?
:-)
^L
Useful.
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.
gcc is not just an Ada
Mike Stump wrote:
On Nov 28, 2005, at 3:00 AM, Richard Earnshaw wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
Logic would suggest that a program is unpredictable if written in such a
way that
On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
While it is true that GCC is not just an Ada compiler but I think
we should
follow a sane set of rules for GNU C which might mean following
Ada's rules
for this case.
Because GNU C doesn't have rules carefully written to make this
On Nov 28, 2005, at 9:33 AM, Richard Kenner wrote:
And where is the standard for the language known as GNU C?
You can obtain the ISO definition for C from ISO:
61)The intent of this list is to specify those circumstances
in which an object may or may not be aliased.
On Mon, Nov 28, 2005 at 09:53:31AM -0800, Mike Stump wrote:
On Nov 28, 2005, at 9:41 AM, Andrew Pinski wrote:
Huh? they are not carefully written at all. This is why I said what
is GNU C? Again the language is not written out so it means anything.
So then clearly, since it means anything,
On Nov 28, 2005, at 10:08 AM, Joe Buck wrote:
So then clearly, since it means anything, we can change gcc to accept
pascal instead of C? Right? This is absurd.
Mike, you wrote GNU C, not ISO C. There's no spec for the former.
He said we can do anything, this is untrue. I rail against the
All,
This is from an email trail on gcc-patches. I was attempting to clean
up differences in the test suite between -fPIC and no -fPIC tests.
* gcc.dg/assign-warn-3.c: Ditto.
Why in the world do you imagine this should depend on -fpic?
Here's the case that passes (no -fPIC):
He said we can do anything, this is untrue. I rail against the casual
use of the word because it misleads others into believing it, and then
proposing patches that do anything they want, and yet make gcc worse.
I realize there that we have no documentation person that writes down
Mark Mitchell [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| Mark, RTH, could you provide hints?
|
| I don't have any ideas, just from looking atthe problem. It could be a
| stack allocation problem, where we assign two things the same stack
| slot, and get confused.
Thanks!
--
Mike Stump wrote:
gcc is not just an Ada compiler. Clearly, the answer has to be yes to
support GNU C.
Right, I agree, I was answering whether this can ever be done
legitimately, and the answer is really no, it is undefined in
C, and if you manage to do it in Ada, which you can if you
Mike Stump wrote:
I disagree. For example, there is behavior mandated by the Standard
for C, such as this, that, reasonably, I think we have to follow. You
can argue that we don't have to follow the standard but I'm not just
going to listen to you.
Hmm, I guess I misread the standard,
Gabriel Dos Reis [EMAIL PROTECTED] writes:
| I'm running the pre-releasing script, so a new prerelease tarball will be
| available today.
The tarballs are available for download and testing here:
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.5-20051128/
-- Gaby
On Nov 28, 2005, at 11:05 AM, Robert Dewar wrote:
Right, I agree, I was answering whether this can ever be done
legitimately, and the answer is really no, it is undefined in
C
It is not.
On Nov 28, 2005, at 11:12 AM, Robert Dewar wrote:
Mike Stump wrote:
I disagree. For example, there is behavior mandated by the
Standard for C, such as this, that, reasonably, I think we have
to follow. You can argue that we don't have to follow the
standard but I'm not just going to
Mike Stump wrote:
Only in one direction does the standard make it undefined, as I
quoted. I know why they do this, and I am arguing that that latitude
should not be used to try and `optimize' things to make them behave
differently (such as calling abort for example) in the presence of
Robert Dewar [EMAIL PROTECTED] writes:
[...]
| I do agree that if
|
| a) everyone agrees on what the sensible definition is
We do have a standard definied beahviour.
| b) the optimization is not valuable
for those people who don't care about the standard semantics, there is
always an option
Chris == Chris Lattner [EMAIL PROTECTED] writes:
Only the Ada frontend seems to be in a state to maybe support direct
frontend IR to LLVM translation.
Chris Sure, also maybe Fortran?
FWIW gcjx was designed to make this easy to do. And just yesterday a
volunteer started working on a
On Nov 28, 2005, at 10:55 AM, Richard Kenner wrote:
It's not that simple and I suspect you know it.
Yes, this is all fine and very well, but do you realize that Andrew
wanted to break gcc behavior as mandated by the ISO standard? This
is very, very simple. The answer is no. I'm
On Nov 28, 2005, at 10:42 AM, Kean Johnston wrote:
* gcc.dg/assign-warn-3.c: Ditto.
Why in the world do you imagine this should depend on -fpic?
And here is the case that fails (-fPIC). I have no idea why those
warnings are not being ejected when compiling with -fPIC. Perhaps I
Chris == Chris Lattner [EMAIL PROTECTED] writes:
Chris In this role, it provides a static optimizer, interprocedural link-
Chris time optimizer, JIT support, and several other features.
I'm quite interested in the JIT aspect of LLVM, for gcj.
This would fill one of our major missing gaps.
Tom Tromey writes:
Java is fairly dynamic, as I'm sure you know. So, I'm much more
interested in the JITting possibilities than in link time
optimizations; the latter is cool and probably useful to embedded
users of gcj, but I'd imagine for all our recent binary compatibility
On Nov 28, 2005, at 12:40 PM, Andrew Pinski wrote:
I was, there was no where in I was saying we should break ISO standard
The effect of following Ada's rules:
While it is true that GCC is not just an Ada compiler but I think
we should
follow a sane set of rules for GNU C which might mean
On Nov 28, 2005, at 12:40 PM, Andrew Pinski wrote:
I was, there was no where in I was saying we should break ISO standard
The effect of following Ada's rules:
While it is true that GCC is not just an Ada compiler but I think
we should
follow a sane set of rules for GNU C which
On Mon, Nov 28, 2005 at 12:45:41AM -0800, Jim Blandy wrote:
On 11/27/05, Jonathan Wakely [EMAIL PROTECTED] wrote:
Yes, I know it's a wiki and I can do this myself, but I only have so
much spare time and maybe the second one was added for a good reason.
http://en.wikipedia.org/wiki/Be_bold
We're collectively putting a lot of energy into performance improvements
in GCC. Sometimes, a performance gain from one patch gets undone by
another patch -- which is itself often doing something else beneficial.
People have mentioned to me that we require people to run regression
tests for
Andrew Haley wrote:
Bernd Schmidt writes:
Hmm, we can trap null pointer accesses, but I don't think we deliver
reliable SIGSEGV signals yet or provide a means of getting the faulting
address. If that was fixed, is there anything obvious that stands in
the way of a
Frank Cusack wrote:
See URL:http://bugzilla.redhat.com/bugzilla for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
- the bug is quite reproducible, why does gcc say otherwise?
This is due to a patch that Red Hat has added to the FSF gcc sources.
When a
On Mon, Nov 28, 2005 at 04:38:58PM -0800, Mark Mitchell wrote:
Clearly, performance testing is harder than correctness testing;
correctness is binary, while performance is a continuum. Machine load
affects performance numbers. It's reasonable to strive for no
correctness regressions, but
Joe Buck wrote:
It would be possible to detect performance regression after fact, but
soon enough to look at reverting patches. For example, given multiple
machines doing SPEC benchmark runs every night, the alarm could be raised
if a significant performance regression is detected.
Right; I
On Nov 28, 2005, at 4:38 PM, Mark Mitchell wrote:
we require people to run regression tests for correctness, but that
we don't really have anything equivalent for performance.
My feeling is that we should have such a suite. I'd favor a micro
style, where we are measuring clock cycles (on
I was hoping that having it there when people did test runs would change
the psychology; instead of having already checked in a patch, which
we're then looking to revert, we'd be making ourselves aware of
performance impact before check-in, even for patches that we don't
expect to have
Back in 1999, Torbjorn Granlund posted:
http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html
That message contains an IEEE floating-point emulation library, like
fp-bit.c. Howeve, the performance is considerably better; Joseph
measured against fp-bit.c with a modern compiler, and ieeelib.c is about
On Tue, Nov 29, 2005 at 02:03:46AM +, Paul Brook wrote:
I was hoping that having it there when people did test runs would change
the psychology; instead of having already checked in a patch, which
we're then looking to revert, we'd be making ourselves aware of
performance impact before
On Mon, Nov 28, 2005 at 06:05:34PM -0800, Mark Mitchell wrote:
Back in 1999, Torbjorn Granlund posted:
http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html
That message contains an IEEE floating-point emulation library, like
fp-bit.c. Howeve, the performance is considerably better; Joseph
Joe Buck wrote:
Well, the problem is that you're raising a legal technicality, and legal
technicalities are up to the FSF. Maybe they'll have no problem,
especially if Swox AB basically is Torbjorn. If there is a problem, and
Torbjorn is still CEO of Swox AB, it should be no problem (other
Mark Mitchell writes:
Mark In his original message, Torbjorn indicated that Swox AB (the company of
Mark which he is CEO) donated the code, and the old copyright file had an
Mark entry for Torbjorn, though not Swox AB. I've contacted Torbjorn, and
Mark he'd still like to see ieeelib.c in GCC.
Again, that's a strawman. I'm just looking for suggestions about what
we might to do -- or even feedback that there's no need to do anything.
This isn't really suitable for an automated tester, but what I used to do was
keep around some .i files of some version of some compiler files (I
On Mon, 28 Nov 2005, Jim Wilson wrote:
The DWARF2 unwind info method has little or no overhead until a
exception is thrown. This is the preferred method for most targets. In
this scheme, we read the DWARF2 unwind info from the executable when an
exception is throw, parse the unwind tables,
David Edelsohn wrote:
Swox AB does have a copyright assignment on file, so GCC is free
to use ieeelib.c.
Great. Thanks for double-checking!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
I had some problems when trying to use the apple branch on a gnu/linux/x86.
Because of this I am trying to port the patch to the trunk. With some help
from Chris I am now able to build xgcc, but a type check fails when it is
run:
../../trunk-llvm/gcc/crtstuff.c:186: internal compiler error:
On Nov 28, 2005, at 6:21 PM, Hans-Peter Nilsson wrote:
I've attached the work-in-progress so I don't have to get into
detail about what it does :-) except noting that you'll see in
gcc.sum something like:
PASS: csibe -O1 runtime zlib-1.1.4:minigzip not slower than best
PASS: csibe -O1 runtime
Is this indeed a bug?
Sounds like a bug.
I just found something in the bug database relating to this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19232
According to Andrew (#3) it doesnt eject a warning becuase
the function isn't inlined. I'm not sure thats a valid
reason for not ejecting
There is an upsteam for beohm_gc (Boehm himself).
Yes, but you usually can modify the local copy and simply CC Hans.
--
Eric Botcazou
On Mon, 28 Nov 2005, Mike Stump wrote:
On Nov 28, 2005, at 6:21 PM, Hans-Peter Nilsson wrote:
I've attached the work-in-progress so I don't have to get into
detail about what it does :-) except noting that you'll see in
gcc.sum something like:
PASS: csibe -O1 runtime zlib-1.1.4:minigzip
--nextPart1783728.bJoWQadrrL
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I had some problems when trying to use the apple branch on a gnu/linux/x86.=
=20
Because of this I am trying to port the patch to the trunk.
I threw the current version of the patch up here:
http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
A couple of comments.
getIntegerType is really badly. It seems better to use
the mode to detect the type.
Also maping 128bit fp type to {double, double} seems wrong
for almost all targets
On Tue, 29 Nov 2005, Andrew Pinski wrote:
I threw the current version of the patch up here:
http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
A couple of comments.
getIntegerType is really badly. It seems better to use
the mode to detect the type.
Also maping 128bit fp type to {double,
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-28 07:08
---
No, it's in fact easier than that. We shouldn't come into us_read for this
file, which is formatted! Probably a bad default flag is set.
I think you are right. I have
--- Comment #5 from jvdelisle at verizon dot net 2005-11-28 08:09 ---
Subject: Re: namelist read from non-opened file
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-28 07:08
---
No, it's in fact easier than that. We
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-28 09:27
---
Fixed on 4.1 and 4.2. Won't be fixed on 4.0.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
gcc version: gcc-3.3.3
system type: IBM AIX 64bit 5.3.3
I am trying to compile a 64bit version of gcc-3.4.2 using gcc-3.3.3 (32bit) on
a PowerPC AIX 5.3 64bit.
My configure:
export OBJECT_MODE=64
export CC=gcc
export CXX=g++
export CFLAGS=-O2 -maix64 -g -mminimal-toc
export
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-11-28 09:33
---
Well, at least that one should be easy (L without a width specifier is an
extension, and the width is then taken to be 1). I'm on it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-28 10:19 ---
(In reply to comment #4)
Subject: Re: [3.4 only] [hppa] 'bus error' at runtime while passing a special
struct to a C++ member function
Are you working on this? It lools like the bug has been there for a while.
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-28 10:20 ---
Postpone until 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-28 10:22 ---
Postpone until 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #3 from nathan at gcc dot gnu dot org 2005-11-28 10:34 ---
Subject: Bug 21166
Author: nathan
Date: Mon Nov 28 10:34:30 2005
New Revision: 107599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107599
Log:
.:
PR c++/21166
* c-decl.c (finish_struct):
--- Comment #2 from bonzini at gnu dot org 2005-11-28 10:53 ---
Created an attachment (id=10352)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10352action=view)
patch to fix the bug
Kaz, can you please test this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
The following program should occur an error since the same named
entity from different modules cannot be referenced.
However, I compiled successfully, and got output foo.
I think it is wrong behavior.
module m_foo
contains
subroutine foo
print *, foo
end subroutine
end module
module
--- Comment #3 from kkojima at gcc dot gnu dot org 2005-11-28 12:30 ---
It fixes the ICE and produces better codes. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
--- Comment #5 from johannes at sipsolutions dot net 2005-11-28 12:39
---
Hm. I didn't use -lrtgcc, that must have been a typo/copypaste error, I
definitely used -lrt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25118
--- Comment #2 from zerocool at modemsoft dot it 2005-11-28 12:48 ---
Subject: GCC Java not compile
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-25
20:14 ---
Can you attach the source you are trying to compile?
I have taken the source of the gcc 4.02 from
--- Comment #4 from giovannibajo at libero dot it 2005-11-28 13:01 ---
Out of curiosity, can you show the code before and after Paolo's patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 13:19 ---
Confirmed, IFC gives:
fortcom: Error: The same named entity from different modules and/or program
units cannot be referenced. [FOO]
in file (null), line 0, column 0
compilation aborted for t.f90 (code 1)
--
--- Comment #5 from kkojima at gcc dot gnu dot org 2005-11-28 13:33 ---
Argh. I've got the results other way around.
Before patch:
--
.global foo
.type foo, @function
foo:
mov.l r12,@-r15
mov.l r14,@-r15
mov r15,r14
mov.l
--- Comment #34 from marc dot waeckerlin at siemens dot com 2005-11-28
13:37 ---
What now? What happened since July? There's not even a new trouble report open
asking for __GCC_PTHREADS__.
What can I as library writer now do, if I want to know whether or not I am in
valid
--- Comment #35 from aoliva at gcc dot gnu dot org 2005-11-28 14:15 ---
Created an attachment (id=10353)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10353action=view)
Pach that fixes the weakref behavior on darwin
Could someone with access to the affected OS please try this
gcc.c-torture/compile/20050303-1.c fails when it is compiled with
m68k-elf-gcc -m5200 -O0.
gcc.c-torture/compile/20050303-1.c:10: error: insn does not satisfy its
constraints:
(insn 17 45 18 (set (mem/c/i:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -12 [0xfff4])) [0 toread+0 S4
The following code:
struct S
{ int x[3]; };
void f()
{ S s = {1,2,3};}
With -Wmissing-braces (which is implied by -Wall, among others) gives:
warning: missing braces around initializer for 'int [3]'
In the specific case where a struct contains only a single array, adding the
extra braces
Consider
double
foo (unsigned int a)
{
return a;
}
int
main (void)
{
return 0;
}
When I compile and link this like so
m68k-elf-gcc -Wl,-T,sim.ld -o test test.c
I get
undefined reference to `__floatunsidf'
Inspection of m5200/libgcc.a reveals that it does not contain __floatunsidf.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 14:52 ---
I don't see why the warning is not useful at all, in fact I rather have the C++
standard fix their wording of TR1's array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 14:49 ---
I think this is a 4.2 regression cause by JSM's patch, could you check to see
if this is a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25138
--- Comment #2 from chris at bubblescope dot net 2005-11-28 15:17 ---
Thats an option too, but I thought I'd see about gcc's opinion first, as I
expected a much faster reply than I would get from the C++ steering committee
:)
I find the warning helpful for constructs like:
struct S {
--- Comment #6 from krebbel at gcc dot gnu dot org 2005-11-28 15:34 ---
Created an attachment (id=10354)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10354action=view)
Testcase which failes on S/390 64bit with -O2
This testcase is reduced from gengtype-lex.c. Due to this bug it
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-28
15:36 ---
I think you are right. I have been putting in debug statements all over and
find that we are asking the wrong length of reads, 8 characters, instead of 1
in the failing case. I will get back to this
--- Comment #36 from dir at lanl dot gov 2005-11-28 15:53 ---
With patches gcc41-pr24991.patch (I also need this to build on LINUX) and
gcc-weakref-darwin.patch (the patch gcc/ChangeLog failed, but that did not
matter) installed and a fresh down load of gfortran, gfortran builds and I
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-28 15:59
---
I think the following patch (no time yet to regtest it, and won't have time
soon, please feel free to test it) fixes it:
Index: transfer.c
===
---
--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-28 16:03
---
Confirmed. This appears to be a bug in noce_try_abs, which is substituting an
abs() expansion into the RTL, but the substitution clobbers a hard register
that is live (the condition code register).
--
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-28 16:15
---
Subject: Re: Warning missing braces around initializer causing problems with
tr1::array
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| I don't see why the warning is not useful at all, in fact I
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-28 16:18
---
Subject: Re: New: Warning missing braces around initializer causing
problems with tr1::array
chris at bubblescope dot net [EMAIL PROTECTED] writes:
| The following code:
|
| struct S
| { int x[3]; };
|
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-28 16:28 ---
fold_range_test is wrong, around fold-const.c:4635
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23518
--- Comment #5 from chris at bubblescope dot net 2005-11-28 16:28 ---
I'll make a report. Don't worry, I'm clear on the difference between tr1::array
and a C array, I just wanted to check that we agree this should produce a
warning (in which case I will go through the tr1::array
--- Comment #6 from chris at bubblescope dot net 2005-11-28 16:33 ---
Actually, is a report really approriate? Writing arrayint,3 = {1,2,3} is
perfectly valid C++, just warned about with -Wmissing-braces
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #6 from johannes at sipsolutions dot net 2005-11-28 16:34
---
And shouldn't a header/library mismatch segfault without optimisation as well?
But if it works for you I'll just see with the next gcc version I get.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25118
I have been getting this error on one of my programs that does extremely
complex I/O operations for a few months now, but I have been unable to isolate
it. I finally got the same error message from a program that generates random
I/O patterns. About half of the FORTRANS that I run this program
The following program:
extern void abort (void);
int x = 0;
extern int y __attribute((weakref(x)));
int main(void)
{
x = 1;
y = 2;
if (x != 2)
abort ();
return 0;
}
when compiled with -O2 on powerpc-darwin, unconditionally calls abort(). It
should not.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 17:06 ---
Confirmed, the problem is that middle-end does not know that x and y are really
the same variable
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I get a segmentation fault when trying to execute the
following simple program:
cat junk2.f
program junk
character*28000 s
do i=1,28000
s(i:i) = 'a'
end do
open(3,file='junk_file',form='unformatted',access='direct',
recl=28000)
write(3,rec=1)
1 - 100 of 167 matches
Mail list logo
