--- Comment #13 from jakub at gcc dot gnu dot org 2008-02-13 08:29 ---
I'm not sure it is a good idea to change semantics of force_gimple_operand
this late in 4.3 cycle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
--- Comment #10 from bonzini at gnu dot org 2008-02-13 08:44 ---
I doubt it is a 4.3 regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-02-13 08:44
---
I'm not sure it is a good idea to change semantics of force_gimple_operand
this late in 4.3 cycle.
It's not really a change of semantics, it only bridges the gap between two
functions that are supposed to
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-13 08:59
---
(In reply to comment #5)
The patch causes several regressions. hollerith.f90 for example.
I knew I was missing something :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2008-02-13 09:02
---
Closing as INVALID, this is an Apple bug in 10.5.0 and 10.5.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from Rudolf dot Leitgeb at gmx dot at 2008-02-13 08:45
---
Dear Eric,
thanks for the patch, I already knew that one from here:
http://winavr.cvs.sourceforge.net/winavr/patches/gcc/4.2.2/21-gcc-4.2.2-disable-libssp.patch?view=markup
I just wanted to point out that I
--- Comment #11 from dominiq at lps dot ens dot fr 2008-02-13 09:33 ---
At rev. 132272 gcc.target/i386/pr35160.c fails on i686-apple-darwin9 with:
[ibook-dhum] dominiq/Desktop% /opt/gcc/gcc4.3w/bin/gcc
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/pr35160.c
--- Comment #4 from nickc at redhat dot com 2008-02-13 10:45 ---
Created an attachment (id=15135)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15135action=view)
Suppress elimination of the frame pointer to the stack pointer in thumb mode
--
--- Comment #5 from nickc at redhat dot com 2008-02-13 10:49 ---
Hi Jim,
Given that this bug does not exist in the more modern 4.x gcc series I am
tempted to just suggest that you upgrade your toolchain. On the assumption
however that this is not a viable option for you I have
--- Comment #15 from manu at gcc dot gnu dot org 2008-02-13 11:13 ---
I am going to close this as a duplicate of 5645 and post a patch there that
includes the testcases of both PRs. Both bugs are about the definition (or lack
of it) of this warning.
*** This bug has been marked as a
--- Comment #8 from manu at gcc dot gnu dot org 2008-02-13 11:13 ---
*** Bug 11159 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-02-13 11:16 ---
Subject: Bug 29673
Author: manu
Date: Wed Feb 13 11:15:51 2008
New Revision: 132284
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132284
Log:
2008-02-13 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 29673
Hi all,
I see a little error in the french traduction off gcc.
Example :
gcc :
src/main.c:13: attention : déclaration sasn effet
will be in correct french :
src/main.c:13: attention : déclaration sans effet
thanks for all.
--
Summary: Error in the french traduction
--- Comment #9 from manu at gcc dot gnu dot org 2008-02-13 11:23 ---
Created an attachment (id=15136)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15136action=view)
patch and testcases
This patch contains an attempt to implement the suggestions given here:
--- Comment #10 from manu at gcc dot gnu dot org 2008-02-13 11:38 ---
Created an attachment (id=15137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15137action=view)
patch and testcases
Correct patch, the previous one did not contain pr11159.C
--
manu at gcc dot gnu dot org
--- Comment #4 from manu at gcc dot gnu dot org 2008-02-13 11:42 ---
Subject: Bug 29673
Author: manu
Date: Wed Feb 13 11:41:23 2008
New Revision: 132285
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132285
Log:
2008-02-13 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 29673
--- Comment #5 from manu at gcc dot gnu dot org 2008-02-13 11:42 ---
Fixed code and doc in 4.3.0, fixed doc in 4.2.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from markus at unixforces dot net 2008-02-13 13:06 ---
(In reply to comment #7)
However, gcc-4.1 is a bit old now...
I'm marking this bug as WONTFIX then.
--
markus at unixforces dot net changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-02-13 13:26 ---
I am looking into it. Obviously cgraph is out of sync for whatever reason.
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
This bug was noticed on sh but potentially impacts other STRICT_ALIGNMENT
targets.
The attached test case reduces a misaligned field access from an array of
packed structs. In this example compiled with -O2 the field wMaxPacketSize is
accessed (on sh4) with a mov.w instruction although it is
--- Comment #1 from chrbr at gcc dot gnu dot org 2008-02-13 13:42 ---
Created an attachment (id=15138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15138action=view)
gcc testsuite case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35178
--- Comment #2 from chrbr at gcc dot gnu dot org 2008-02-13 13:45 ---
Created an attachment (id=15139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15139action=view)
Proposed patch
regression tested on sh-superh-elf and sh4-linux-gnu.
and bootstraped for i686-pc-linux-gnu.
--
--- Comment #6 from pbrook at gcc dot gnu dot org 2008-02-13 14:17 ---
I agree with Nick. Unless there's some evidence that this bug still exists in
versions of gcc that we still support, I'm going to put this down to general
3.4 brokeness and assume it has already been fixed.
The
--- Comment #9 from joel at gcc dot gnu dot org 2008-02-13 13:59 ---
Also fails on
powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision
132202]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-13 14:27 ---
patches should be sent to the gcc-patches mailing list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35178
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-13 14:33 ---
This is just what is expected.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from matz at gcc dot gnu dot org 2008-02-13 14:54 ---
Subject: Bug 35065
Author: matz
Date: Wed Feb 13 14:53:59 2008
New Revision: 132286
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132286
Log:
PR debug/35065
* var-tracking.c
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-02-13 15:12
---
variable tracking : 6.52 (17%) usr 0.10 ( 7%) sys 6.62 (17%) wall
41452 kB (25%) ggc
so this is still in the same order of magnitude than with the earlier reports.
--
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-02-13 15:03
---
I'll leave this PR open because the testcase shows the bad compile-time
performance of the var-tracking df solver in general. The original bug,
infinite compile-time is probably fixed.
--
rguenth at gcc dot
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-02-13 14:33
---
So, what exactly is wrong now? And what is this IVOPTs problem? ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
--- Comment #1 from lakshmivaraganm at hcl dot in 2008-02-13 15:37 ---
The same problem is there in 3.4.6 version too:
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-13 15:46 ---
Try a still maintained compiler which would be version 4.1.2 at least, and
specify the target you observe the bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from sebor at roguewave dot com 2008-02-13 15:46 ---
I used setrlimit() only to emulate low disk space conditions. The same
problem
occurs in a pure C++ program (i.e., one that makes no POSIX or other non-C++
calls) when it really does run out of disk space.
So again,
--- Comment #10 from matz at gcc dot gnu dot org 2008-02-13 15:00 ---
This is fixed now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dominiq at lps dot ens dot fr 2008-02-13 16:00 ---
The test gcc.dg/pr35065.c fails on i686-apple-darwin9 with:
FAIL: gcc.dg/pr35065.c (test for excess errors)
Excess errors:
/opt/gcc/gcc-4.3-work/gcc/testsuite/gcc.dg/pr35065.c:33: warning:
initialization makes
--- Comment #12 from matz at gcc dot gnu dot org 2008-02-13 16:18 ---
Whoops, sorry. I fixed the warnings in a different copy of the testcase
than the one I committed :-( Committed the right version now. (Yes, it still
tests what it should test, without the var-tracking patch it runs
--- Comment #19 from dominiq at lps dot ens dot fr 2008-02-13 16:07 ---
I am quite confused by the following:
STACK_BOUNDARY to 128,
while linux to 4.
...
If you do not align the stack at a 128-bit boundary, your program will
crash. The hardware that it is related to is SSE2.
--- Comment #33 from eyal at geomage dot com 2008-02-13 16:06 ---
Hi All,
I've done some changes that hopefully prevent the memory from being a
performance bottleneck. I see a perf gain of ~10%. However the compiler still
gives me the warnings in comment #19 -
Test.cpp:24: note:
--- Comment #18 from hjl dot tools at gmail dot com 2008-02-13 15:39
---
(In reply to comment #17)
It is to be expected that this proposal usually has no effect on
Darwin, because the problem it is trying to solve, of local variables
that require alignment greater than the
--- Comment #4 from schwab at suse dot de 2008-02-13 16:08 ---
POSIX requires that write generates SIGXFSZ if the limit is exceeded (on
systems that support the XSI extensions).
--
schwab at suse dot de changed:
What|Removed |Added
+++ This bug was initially created as a clone of Bug #5925 +++
The same bug happens in gcc version 3.4.3 too:
Given below are the details:
The same problem is experienced in gcc version given below:
Reading specs from /VOBS/sol10tools/gcc/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Configured with:
--- Comment #20 from ubizjak at gmail dot com 2008-02-13 16:18 ---
(In reply to comment #19)
STACK_BOUNDARY to 128,
while linux to 4.
In which unit is expressed STACK_BOUNDARY? If linux set it to 4, is it correct
to understand that it is bytes and not bits (4 bits would not make
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-13 16:56 ---
Calling the C stdio functions will result in the same behavior, so the as-if
rule is satisfied.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ubizjak at gmail dot com 2008-02-13 16:42 ---
(In reply to comment #11)
At rev. 132272 gcc.target/i386/pr35160.c fails on i686-apple-darwin9 with:
i686-apple-darwin-9 implies -fpic, so one register less is available.
This is a testsuite failure, following patch
--- Comment #5 from sebor at roguewave dot com 2008-02-13 16:37 ---
I understand that POSIX requires the signal but I'm not sure I see what that
has to do with filebuf. C++ specifies that filebuf member functions behave
as if by calling the C stdio functions.
See 27.8.1, p2:
In this
--- Comment #21 from dominiq at lps dot ens dot fr 2008-02-13 16:40 ---
Currently, it is defined as:
#define STACK_BOUNDARY BITS_PER_WORD
In this case how can it be 4? should not it be 32 or 64?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
--- Comment #1 from kltstallard at gmail dot com 2008-02-13 17:26 ---
Created an attachment (id=15140)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15140action=view)
Preprocessed file that causes the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35181
Note that this version of the compiler is experimental on the QNX platform.
When compiling the attached preprocessed file I get the following message:
qcc -V4.2.1,gcc_ntox86_cpp -w1 -IC:\QNX632\ARICommon
-IC:\QNX632\ARICommon\include -c -g -Wc,-Wall -oTNSTypeDef.o ..\TNSTypeDef.cpp
Seems to be the same for most of the other built-in-setjmp tests on this
target.
Memory exception at fff4 (illegal address)
Unexpected trap (0x 9) at address 0x020013D8
data access exception at 0xFFF4
This occurs after the __builtin_longjmp() transfer control back to main().
--
--- Comment #23 from pinskia at gcc dot gnu dot org 2008-02-13 17:18
---
Why is it STACK_BOUNDARY on PowerPC to 128 (for both AIX and Darwin) and why
does it work that way and x86 does not work that way?
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
--- Comment #22 from ubizjak at gmail dot com 2008-02-13 17:03 ---
(In reply to comment #21)
Currently, it is defined as:
#define STACK_BOUNDARY BITS_PER_WORD
In this case how can it be 4? should not it be 32 or 64?
Yes, it _is_ 32 or 64. The point is, that IT IS NOT 128, so
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-02-13 17:05 ---
Subject: Bug 21655
Author: ghazi
Date: Wed Feb 13 17:04:46 2008
New Revision: 132289
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132289
Log:
Backport:
2005-11-30 Richard Guenther [EMAIL
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
GCC
--- Comment #18 from tbptbp at gmail dot com 2008-02-13 17:21 ---
Ah ah!
[svn pull... build...]
Sadly it makes no difference yet, most certainly because of all the kludges i
had to stuff in: out of the 2213 tests (from the ucb-corpus for +,-,*,/,sqrt)
there's still 3 of them (all
The following testcase produces an ICE. I couldn't reduce it any further. Fails
with GCC 4.2.2/4.2.3 under i686-pc-linux-gnu/i686-pc-mingw32.
#include tr1/array
#include tr1/memory
int main()
{
typedef std::tr1::arraystd::tr1::shared_ptrint, 1 Array;
Array array;
for
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-02-13 17:29 ---
This one liner actually took me a while. It is quite ugly ordering issue.
Index: ipa.c
===
--- ipa.c (revision 132243)
+++ ipa.c (working
I just tried to compile Suse Linux package dasher-4.7.0-4
with the GNU C++ compiler version 4.3 snapshot 20080208
The compiler said
Alphabet/AlphIO.cpp: In member function 'void
Dasher::CAlphIO::CreateDefault()':
Alphabet/AlphIO.cpp:361: error: void value not ignored as it ought to be
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-13 17:33 ---
../TNS.cpp:27: error: template arguments to
'TNSTypeDefTHelpervoid::s_createStaticTNSTypeDefT' do not match original
template 'TNSTypeDefTHelperT::s_createStaticTNSTypeDefT'
../TNS.cpp:27: note: use template for an
--- Comment #17 from pinskia at gcc dot gnu dot org 2008-02-13 17:33
---
*** Bug 35181 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
System: Ubuntu 7.10
gcc version: 4.2.0
Problem: Using openmp extension
erro interno de compilação: in create_tmp_var, at gimplify.c:487
--
Summary: ICE using openmp with g++-4.2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity:
--- Comment #8 from mark at codesourcery dot com 2008-02-13 18:18 ---
Subject: Re: [4.0/4.1/4.2/4.3 regression] ICE with VLA in
template function
jason at gcc dot gnu dot org wrote:
Either value_dependent_expression_p needs to handle arbitrary VLA bounds, or
we
need to avoid
--- Comment #4 from edgurgel at gmail dot com 2008-02-13 18:33 ---
G++ gives
raycaster.cpp: In member function void Raycaster::cast() const:
raycaster.cpp:43: erro interno de compilação: in create_tmp_var, at
gimplify.c:487
Por favor, envie um relato completo de erro,
com o código
--- Comment #7 from sebor at roguewave dot com 2008-02-13 18:15 ---
I see I should have checked the actual stdio behavior instead of relying on
the standard. Recent Linux and Solaris both do, in fact, generate SIGXFSZ out
of C stdio. AIX 5.3 does not, and neither does HP-UX 11.23,
--- Comment #3 from edgurgel at gmail dot com 2008-02-13 18:31 ---
Created an attachment (id=15144)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15144action=view)
.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35185
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #24 from ubizjak at gmail dot com 2008-02-13 18:11 ---
(In reply to comment #23)
Why is it STACK_BOUNDARY on PowerPC to 128 (for both AIX and Darwin) and why
does it work that way and x86 does not work that way?
Don't know rs6000 to tell, but it looks to me that for i686
The following code triggers an ICE with gcc-4.3-20080208
foo.f90
MODULE foo
TYPE, PUBLIC :: bar
PRIVATE
REAL :: value
END TYPE bar
INTERFACE ASSIGNMENT (=)
MODULE PROCEDURE assign_bar
END INTERFACE ASSIGNMENT (=)
CONTAINS
ELEMENTAL SUBROUTINE assign_bar (to, from)
--- Comment #1 from dcb314 at hotmail dot com 2008-02-13 17:59 ---
Created an attachment (id=15141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15141action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35183
--- Comment #7 from jason at gcc dot gnu dot org 2008-02-13 18:14 ---
The problem is that value_dependent_expression_p expects to only be called with
constant-expression arguments, but a VLA leads to calling it with a
non-constant expression argument, and we abort when we notice a cast
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-02-13 18:15
---
I must say that I don't see it that safe: we can't clone the functions because
at the time fronend decide to rewrite the body by new one we are not having
functions gimplified yet. (well we can clone, but we want
--- Comment #1 from edgurgel at gmail dot com 2008-02-13 18:30 ---
Created an attachment (id=15142)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15142action=view)
source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35185
--- Comment #2 from edgurgel at gmail dot com 2008-02-13 18:30 ---
Created an attachment (id=15143)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15143action=view)
header
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35185
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #19 from jason at gcc dot gnu dot org 2008-02-13 18:44 ---
Subject: Bug 34774
Author: jason
Date: Wed Feb 13 18:43:34 2008
New Revision: 132292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132292
Log:
PR c++/34774
* pt.c
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-02-13 19:06 ---
One issue is we have two standards here. The POSIX one and the C++ one. Now
getrlimit/SIGXFSZ signal is a POSIX issue while using filebuf is a C++ one.
Now does POSIX talk about filebuf ?
--
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-13 19:06 ---
Missed changing state on previous change. Closed.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-13 19:10 ---
Grrr.. need to get over sinus headache. Misread Bugzilla. Nothing happened to
this PR. I haven't retried sh for Ada to even know.
--
joel at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 19:22 ---
psABI is only for C last time I remembered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35186
--- Comment #10 from rwild at gcc dot gnu dot org 2008-02-13 19:28 ---
Subject: Bug 35148
Author: rwild
Date: Wed Feb 13 19:27:34 2008
New Revision: 132295
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132295
Log:
PR other/35148
* Makefile.in (gcc-vers.texi): Use abs_srcdir for
DImode is aligned at 4 byte according to i386 psABI. This 4.4 patch
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00184.html
will use 4byte alignment for DImode. But Ada doesn't follow i386 psABI.
validate_alignment in ada/decl.c does
new_align = UI_To_Int (alignment);
...
align = MAX (align,
--- Comment #19 from joel at gcc dot gnu dot org 2008-02-13 19:05 ---
Patch applied to SVN trunk as revision 132294.
Thanks for approving it Arnaud.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from joel at gcc dot gnu dot org 2008-02-13 19:05 ---
Subject: Bug 35143
Author: joel
Date: Wed Feb 13 19:04:53 2008
New Revision: 132294
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132294
Log:
2008-02-11 Joel Sherrill [EMAIL PROTECTED]
PR ada/35143
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-02-13 19:50
---
I'll look into this once 4.3.0 is released.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-02-13 19:37 ---
Ada should either define its own alignment, independent of psABI, or it
should just follow psABI for alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35186
--- Comment #2 from hjl dot tools at gmail dot com 2008-02-13 19:35 ---
maybe_pad_type has
if (align == TYPE_ALIGN (type))
align = 0;
if (align == 0 !size)
return type;
...
record = make_node (RECORD_TYPE);
That is Ada expects 8 byte alignment for DImode. But
--- Comment #20 from jason at gcc dot gnu dot org 2008-02-13 19:30 ---
Please submit a separate bug report for the folding issue, with a reduced
testcase if possible.
Incidentally, the no integral type can represent issue is due to one of the
enumerators being -31, and one being
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-02-13 19:40
---
Thanks for opening the PR However:
DImode is aligned at 4 byte according to i386 psABI.
Of course the psABI doesn't say anything about DImode, only about long long.
DImode is an internal concept of the GCC
--- Comment #12 from rwild at gcc dot gnu dot org 2008-02-13 20:27 ---
Fixed.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-02-13 20:25 ---
Confirmed.
Seems to be related to ELEMENTAL and IN probalby not having a proper array
descriptor. If my_sub is written as:
SUBROUTINE my_sub (in, out)
TYPE(bar), DIMENSION(42, 42) :: in, out
out(1, 1:42)
--- Comment #11 from rwild at gcc dot gnu dot org 2008-02-13 20:26 ---
Subject: Bug 35148
Author: rwild
Date: Wed Feb 13 20:25:47 2008
New Revision: 132296
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132296
Log:
PR other/35148
* Makefile.in (gcc-vers.texi): Use abs_srcdir for
The compiler is unable to find inherited template member data from within the
derived class's method. In the sample code, B inherits from A, but within a
method of B, the compiler can not resolve A's member data.
$ /opt/gcc-4.2.2/bin/g++ -v --save-temps dim.cpp
Using built-in specs.
Target:
--- Comment #14 from mrs at apple dot com 2008-02-13 20:49 ---
I think we should do this; further, I think we should add pedantic to it as
well. Only people that want to be hurt by the standard should be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
--- Comment #2 from rwild at gcc dot gnu dot org 2008-02-13 20:34 ---
patch at: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00467.html
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2008-02-13 21:05 ---
This is confirmed. H.J., are you waiting for something to commit to 4.2 or
should this be closed?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2008-02-13 21:08 ---
Is this still a problem in a recent GCC ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
I would consider to be great when this code
if ( (var == 1) (var == 2) ) { body }
would cause a warning, that the body is
unreachable under any circumstances.
I have made several mistakes like this in the
past and it is annoying to track down...
--
Summary: Missing a warning:
--- Comment #3 from jason at gcc dot gnu dot org 2008-02-13 21:28 ---
Subject: Bug 34962
Author: jason
Date: Wed Feb 13 21:27:16 2008
New Revision: 132297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132297
Log:
PR c++/34962, c++/34937, c++/34939
* decl2.c
--- Comment #10 from matz at gcc dot gnu dot org 2008-02-13 21:28 ---
Created an attachment (id=15145)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15145action=view)
patch
Give this patch a test. The problem is that rs6000.c accepts all offsets
in addresses when they are based
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 21:39 ---
This is by the C++ standard design.
See http://gcc.gnu.org/gcc-3.4/changes.html and [temp.dep]/3 in the C++
standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
1 - 100 of 141 matches
Mail list logo
