--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-05 03:18
---
Just for later reference the defintion of what a dependent name is slightly
different now after the DR:
A name is a member of an unknown specialization if the name is a qualified-id
in which the nested-name-specifi
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-05 03:10
---
hold one for a second there is a defect report about this:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#224
See also:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2000/n1251.html
So EDG just
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-05 02:49
---
(In reply to comment #13)
> The error which EDG front-end gives:
> "ComeauTest.c", line 33: error: a reference of type "int &" (not
> const-qualified)
> cannot be initialized with a value of type "double"
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-05 02:33
---
Ok, here is a real testcase which shows that EDG gets it really wrong:
#include
void resize(double&)
{
printf("resize::double\n");
}
void resize(int&)
{
printf("resize::int\n");
}
template
struct List
{
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-05 02:23
---
(In reply to comment #10)
> This is really invalid code as List::D::size does not exist but it can
> only be diagnost at instaination time.
Oh and resize is not declared either but since d->size is dependent as sh
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-05 02:19
---
So it looks like we have found an EDG bug and not a GCC one.
As for
>There is no explicit dependence for List::D on the template parameter.
>The semantics of D do not change depending upon the instantiation of T.
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-05 02:18
---
(In reply to comment #9)
Never mind that, the numbers have changed a little.
Take the following example:
template
struct List
{
struct D { int size; };
D *d;
List &fill(const T &t, int size = -1);
}
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-05 01:58 ---
(In reply to comment #8)
Hmm, I assume you are looking at C++03 and not C++98. I was looking at C++98,
maybe there was some defect report about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
--- Comment #8 from rnewman at compubrite dot com 2005-11-05 01:55 ---
But 14.6.2.1 says: "Inside a template, some constructs have semantics which may
differ from one instantiation to another. Such a construct depends on the
template parameters."
14.6.2.2 [Example
template struct
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-05 01:35 ---
List::D is by
14.6.2.1 pargagraph 1 point 2:
a qufified-id with a nested-name-specifier which contains a class-name that
names a dependent type of whos unqualified-if names a dependent type.
So by those rules it i
--- Comment #6 from janis at gcc dot gnu dot org 2005-11-05 01:31 ---
The submitter's testcase compiles cleanly with a i686-pc-cygwin cross
compiler using r92494 from 20041222. It fails with lots of "uses anonymous
type" errors, but no ICE, with r92877 on 20050104. I've got lots more b
--- Comment #6 from rnewman at compubrite dot com 2005-11-05 01:29 ---
Just to be clear:
List *is* type dependent.
List::D is *not*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-05 01:24 ---
this better be type dependent, otherwise it is just useless really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
--- Comment #4 from rnewman at compubrite dot com 2005-11-05 01:21 ---
See 14.6.2.1 "Dependent names" and 14.6.3 "Non Dependent name"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
--- Comment #3 from ppluzhnikov at charter dot net 2005-11-05 01:17 ---
Another variation of the same theme:
template
List &List::fill(const T &t, int size)
{
this->resize(1);
this->resize(d->size);
return *this;
}
$ /usr/local/gcc-4.1/bin/g++ -c junk.cc
# silently accepte
--- Comment #2 from rnewman at compubrite dot com 2005-11-05 01:13 ---
(In reply to comment #1)
> Hmm, GCC seems to think "size ? 1 : d->size" is type-dependent in a way it is
> as D is type dependent.
I disagree. D is not type depenendent at all -- it is a struct containing
exactly o
--- Comment #5 from janis at gcc dot gnu dot org 2005-11-05 01:00 ---
I tried out a few cross compilers for i686-pc-cygwin over the last few
months. The code compiled cleanly on 20040607. Sometime between then
and 20040709 it started failing with a different ICE from what it gets now.
--- Comment #9 from ian at airs dot com 2005-11-05 01:00 ---
Created an attachment (id=10151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10151&action=view)
Proposed patch
This patch fixes the problem. I'm running tests now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-05 00:55 ---
Hmm, GCC seems to think "size ? 1 : d->size" is type-dependent in a way it is
as D is type dependent. Someone else with more knowlege of the C++ standard
will have to comment.
Another testcase which shows the same i
--- Comment #12 from hubicka at gcc dot gnu dot org 2005-11-05 00:55
---
Subject: Bug 23490
Author: hubicka
Date: Sat Nov 5 00:55:23 2005
New Revision: 106520
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106520
Log:
PR rtl-optimization/23490
* doc/invoke.texi
$ cat junk.cc
template
struct List
{
struct D { int size; };
D *d;
List &fill(const T &t, int size = -1);
};
template
List &List::fill(const T &t, int size)
{
resize(size ? 1 : d->size);
return *this;
}
$ /usr/local/gcc-4.1-20051001/bin/g++ -c junk.cc
# silently accepted
R
--- Comment #24 from uweigand at gcc dot gnu dot org 2005-11-05 00:23
---
Well, the workaround removes the ICE, but constructor handling
appears still broken:
ada/sem_prag.o(.text+0xa58): In function
`sem_prag.analyze_pragma.check_no_identifier':
../../gcc-head/gcc/ada/sem_prag.adb:116
--- Comment #8 from ian at airs dot com 2005-11-04 23:27 ---
No, doing the add in v4hi mode is not the same as doing the add in v8qi mode.
The carry bits will be handled differently.
It's also rather odd that register 81 changed from V4HImode to V8QImode.
Normally a pseudo-register al
--- Comment #7 from steven at gcc dot gnu dot org 2005-11-04 23:26 ---
According to rth on IRC this is indeed absolutely wrong.
So it looks like we may have a combine bug here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22432
--- Comment #5 from kargl at gcc dot gnu dot org 2005-11-04 23:24 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from kargl at gcc dot gnu dot org 2005-11-04 23:21 ---
Subject: Bug 24636
Author: kargl
Date: Fri Nov 4 23:21:36 2005
New Revision: 106510
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106510
Log:
PR fortran/24636
* match.c (gfc_match_stopcode):
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-04 23:17 ---
In the .life1 dump we have:
(insn 41 38 42 2 (set (reg:V2SI 79 [ D.2609 ])
(subreg:V2SI (reg:V8QI 76) 0)) 998 {*movv2si_internal_rex64
(insn_list:REG_DEP_TRUE 32 (nil))
(expr_list:REG_DEAD (reg:V
--- Comment #5 from steven at gcc dot gnu dot org 2005-11-04 22:58 ---
Is anyone going to look into this? Is there a smaller test case at least?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 22:58 ---
Fixed in 4.0.2 and above at least. Most likely a dup of bug 15966.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-04 22:56 ---
For the record, Jakub has apparently dropped this bug from his list to put this
bug back into unassigned state.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
The following on screen description happened:
jacin04 PHITS/src> gcc -v -save-temps -O4 -c mars00.f
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure --prefix=/usr/common/usg/gcc/4.0.1
--with-mpfr-dir=/usr/common/usg/gmp/src/gmp-4.1.4/mpfr/
--with-mpfr=/
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-04 22:18 ---
Subject: Bug 24636
Author: kargl
Date: Fri Nov 4 22:18:22 2005
New Revision: 106509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106509
Log:
PR fortran/24636
* match.c (gfc_match_stopcode):
--- Comment #6 from hp at gcc dot gnu dot org 2005-11-04 21:24 ---
Subject: Bug 23424
Author: hp
Date: Fri Nov 4 21:24:20 2005
New Revision: 106507
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106507
Log:
PR target/23424
* gcc.dg/torture/pr23424-1.c: New test.
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-11-04 21:21
---
Hmm, my patch is not fully correct but the C++ front-end gets this correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from hp at gcc dot gnu dot org 2005-11-04 21:20 ---
Subject: Bug 23424
Author: hp
Date: Fri Nov 4 21:20:24 2005
New Revision: 106506
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106506
Log:
PR target/23424
* config/cris/predicates.md ("cris_bdap
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-04 21:18 ---
A regression test identified the following patch to change handling of
C-style casts for PR c++/14035:
http://gcc.gnu.org/viewcvs?view=rev&rev=89300
r89300 | mmitchel | 2004-10-19 23:24:20 + (Tue, 19 Oct 2004) |
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-04 20:19 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=89280
r89280 | rth | 2004-10-19 17:24:46 + (Tue, 19 Oct 2004) | 4 lines
PR middle-end/17885
* tree.c (rec
--- Comment #10 from law at redhat dot com 2005-11-04 20:11 ---
Band-aid applied for 4.1; Steven's prototype patch may be a better solution as
it only simulates those statements which affect the conditional and doesn't
count those statements (they're likely going to disappear in addition
--- Comment #8 from law at redhat dot com 2005-11-04 20:10 ---
Subject: Re: [4.1 Regression] jump threading
causing excessive code duplication
On Mon, 2005-10-31 at 18:56 -0700, Jeffrey A Law wrote:
> On Mon, 2005-10-31 at 03:43 +, mmitchel at gcc dot gnu dot org
> wrote:
>
--- Comment #18 from dnovillo at gcc dot gnu dot org 2005-11-04 19:57
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00239.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from dnovillo at gcc dot gnu dot org 2005-11-04 19:56
---
Subject: Bug 24627
Author: dnovillo
Date: Fri Nov 4 19:56:28 2005
New Revision: 106502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106502
Log:
PR 24627
* tree-ssa-dce.c (pass_dce, pas
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-04 19:50
---
With array size=2000, timings are:
g77: 2.30 s
gfortran-4.0 (without commited patch): 17.0
gfortran-mainline: 2.66 s
intel: 3.15 s
I think we can close this PR.
--
fxcoudert at gcc dot gnu dot org change
--- Comment #23 from laurent at guerby dot net 2005-11-04 19:29 ---
Add mips and mips64, for reference, workaround patch from Andreas Schwab here:
http://gcc.gnu.org/ml/gcc/2005-11/msg00239.html
Index: ipa-utils.c
===
--- i
--- Comment #21 from olh at suse dot de 2005-11-04 19:15 ---
yes, this patch helps. tested with r106499.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-11-04 18:33
---
Created an attachment (id=10147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10147&action=view)
Patch to try
This patch should fix the issue in the reduced testcase but I don't know if it
fixes it fully, C
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-04 18:21
---
The problem is that ipa-static is looking at the variable because the front-end
marked it as a static variable. Daniel Berlin has sugggested a fix, and I will
test it with the reduced test case and then if you cou
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 18:07
---
That testcase shows that we have a big problem, as local_paca (aka r13) should
be marked as call clobbered.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-04 18:06
---
Variable: local_paca, UID 1270, struct paca_struct *, is global, call
clobbered, default def: local_paca_1
But we get:
# TMT.6_8 = V_MAY_DEF ;
# VUSE ;
foo ();
I don't understand why because to me r13
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-04 18:00
---
(In reply to comment #15)
> This looks like gcc thinks r13 will be trashed by the call to foo() so it
> copies it to a non volatile register for use after the call. Strange that
> this
> didn't happen before the
--- Comment #3 from fang at csl dot cornell dot edu 2005-11-04 17:56
---
Am I correct in expecting that const_cast<...> should pass -Wcast-qual without
warning? That's the way I use it (in the few and rare cases that demand it)
and it's met my expectations thus far. I'm kind of surpri
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-04 17:55
---
This was never confirmed with this exact error, and I've done quite some
testing/debuging and did not experience that particular bug. I think this bug
was "superseded" by PR21547, which I am currently fixing. Clos
--- Comment #6 from bkoz at gcc dot gnu dot org 2005-11-04 17:41 ---
In general, we make no claims as to ABI compliance wrt development/trunk
versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
--- Comment #15 from bergner at vnet dot ibm dot com 2005-11-04 17:38
---
For completeness, here is a minimal test case that shows the problem we are
having:
[EMAIL PROTECTED]:~/olaf/PR24644-4> cat bar.c
register struct paca_struct * local_paca asm("r13");
struct paca_struct { volatil
--- Comment #6 from mesmith dot 15507218 at bloglines dot com 2005-11-04
17:30 ---
The two attached files will change the behavior so that included files are
processed as described in comment #2. I have not checked the results
extensively.
--
mesmith dot 15507218 at bloglines dot co
--- Comment #5 from mesmith dot 15507218 at bloglines dot com 2005-11-04
17:24 ---
Created an attachment (id=10146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10146&action=view)
Source in gcc/libgfortran from FC4 gcc 4.0.1 with patches
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #4 from mesmith dot 15507218 at bloglines dot com 2005-11-04
17:22 ---
Created an attachment (id=10145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10145&action=view)
Source in gcc/fortran from FC4 4.0.1 with patches
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from bkoz at gcc dot gnu dot org 2005-11-04 17:06 ---
Agh. Sorry, I had not realized that I'd filed this six months ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24668
--- Comment #5 from bkoz at gcc dot gnu dot org 2005-11-04 17:05 ---
In addition to the current ability to put visibility attributes on file and
class scope, the ability to put visibility attributes on namespace scope is
desired.
The syntax is straight forward extension of existing visi
--- Comment #14 from ian at airs dot com 2005-11-04 16:09 ---
gcc is free to copy non-volatile variables. It does this in many places and
for many reasons, particularly in the new SSA optimizers in 4.0 and later. I
don't know the details of where it decided to copy the register in this
--- Comment #6 from anlauf at gmx dot de 2005-11-04 15:56 ---
(In reply to comment #2)
> This is invalid code, INT is not allowed in a specification expression.
I'm not a language lawyer, but if I read it correctly, then
INT is a standard intrinsic function and thus allowed in a
restric
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 15:37
---
Since this is only a missed optimization (and this was my bug) closing as fixed
for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 15:36 ---
Since this is only a missed optimization, closing as fixed for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 15:33
---
Still fails on the mainline:
t.c: In function main:
t.c:15: internal compiler error: in assign_stack_temp_for_type, at
function.c:595
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #5 from manfred99 at gmx dot ch 2005-11-04 15:32 ---
1) There is an easy way to circumvent the ICE:
if you add an explicit type conversion for IMAX, such as in
REAL:: AUX1(25000+INT(0.82*float(IMAX)))
the ICE goes away and gfortran compiles it successfully and
withou
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 15:32 ---
Fails on the mainline for me.
t.c: In function g:
t.c:23: internal compiler error: in move_for_stack_reg, at reg-stack.c:1062
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc
--- Comment #7 from anglade at gmail dot com 2005-11-04 15:31 ---
I've simplified to it's (almost) simplest expression the test case:
module mtyp
type t1
integer::a
end type t1
end module mtyp
module atest
use mtyp
type(t1)::ze
contains
subroutine test(ze_in )
use mtyp
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 15:28 ---
Here is a testcase which is better representive of the issue (compile with
-std=c99 -pedantic-errors):
#include
int
main (int argc, char **argv)
{
if ((bool)((1527719483 + 1477819644))) {
}
return 0;
}
bool
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-04 15:25 ---
Closed as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 ---
Woops, that should have been ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 ---
Woops, that should have been ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:09 ---
Fix is on 4.0 branch and trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-04 15:09 ---
Fix is on 4.0 branch and trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:08 ---
Subject: Bug 14358
Author: tromey
Date: Fri Nov 4 15:08:18 2005
New Revision: 106490
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106490
Log:
PR libgcj/14358, libgcj/24552:
* gnu/gcj/conver
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 15:08 ---
3.2.1 is an old compiler and the 3.2 series is no longer being updated, can you
try either a 3.3.6 (note the 3.3 series is not being updated either) or a 3.4.4
or a 4.0.2 GCC?
--
pinskia at gcc dot gnu dot org ch
Reproducable: Very easy to reproduce with the sample code
application provided. PLEASE COMPILE the code with -O2 option.
Product: GCC for ARMV5L
Component: C
Version: 3.2.1. (Reported also in ARM Linux community to
be see with gcc 3.3.4, gcc 3.4.2)
Host Platform: x86 Linux 2.4.x
Target Plat
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:59 ---
(In reply to comment #5)
Oh and one more thing, the use of fold_convert is not the incorrect thing to do
here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-04 14:58 ---
(In reply to comment #4)
> Unfortunately I'm not a gcc expert and really don't know how this should be
> bug-fixed.
The way this bug needs to be fixed is one of the following:
1. the types generated need to be in th
--- Comment #4 from anglade at gmail dot com 2005-11-04 14:54 ---
Hi all,
Looking at the examples of failure due to this bug, I've observed that they are
due to user defined datatype. The function fold_convert seems to handle only
intrinsic datatypes while the examples were using user
2005/11/3, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Thu, Nov 03, 2005 at 02:15:27PM -0700, Shaun Jackman wrote:
> > When an object file is compiled by arm-elf-gcc 4.0.2, nm -S 2.16.*
> > isn't printing the size of static variables. I'd very much appreciate
> > a fix or workaround, if one is out
--- Comment #5 from matz at suse dot de 2005-11-04 14:45 ---
While 4.0 had this fixed, trunk still uses the 'mt' allocator by default
on linux, and hence is incompatible with 3.4 and 4.0 by default. Is that
really intended, or shouldn't also trunk default back to the 'new' allocator?
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 14:33 ---
Hmm, old (C) style casts are weird, IIRC they act as either a static_cast, a
reinterpret_cast, or a const_cast. In this case they are acting like a
const_cast which is what is normally goes and gets rid of a qualifi
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-04
14:27 ---
Subject: Re: ACATS ce3810b segfaults at runtime
> --- Comment #8 from christian dot joensson at gmail dot com 2005-11-04
> 11:24 ---
> Just a ping here... are there any progress on this?
No, I h
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 ---
*** Bug 24673 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 ---
It is the same as PR 20244, the line number changed because fold-const.c has
changed and addded code.
*** This bug has been marked as a duplicate of 20244 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-04 14:19
---
testing fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
Hi,
This bug seems not very different from bug #20244 but happens at a different
line in the same function.
during compilation of my code I get the following error mesage:
[EMAIL PROTECTED] 5common]$ /usr/local/bin/gfortran -c
../../../src/5common/funcofrho_tfw.F90
../../../src/5common/funcofrh
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:05 ---
Removing volatile will change the semantics of the program and therefor not a
bug. GCC docs mention with (I cannot find right now as I am at a Kiosk and it
is hard to find anything) longjmp, volatile is required.
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-04 14:02 ---
This happens in c-typeck.c:build_c_cast:
value = convert (type, value);
/* Ignore any integer overflow caused by the cast. */
if (TREE_CODE (value) == INTEGER_CST)
{
/* If OVALU
--- Comment #4 from rakdver at gcc dot gnu dot org 2005-11-04 13:39 ---
Nevertheless, the fact that boolean_true_node has overflow flag set is wrong,
this should not happen -- shared constants should not be modified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
--- Comment #5 from worm at arrakis dot es 2005-11-04 13:35 ---
Sorry for my stupidity -- the jet-lag after a long trip
seems to affect me --.
Remove the "volatile" statement from the arguments list
of L1foo.
Then the assignments to the variable V1 are moved after
the call to cl_throw()
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
CC|dnovillo at redhat dot com |
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:25 ---
I still cannot reproduce it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Keywords||ice-on-valid
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 13:10 ---
What you are seing is either an assmebler bug or just dwarfdump not supporting
relocations for 64bit. I want to say the latter. This is not a GCC bug.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 ---
*** Bug 24668 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 ---
This is a dup of bug 21764 as far as I can see.
*** This bug has been marked as a duplicate of 21764 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
1 - 100 of 128 matches
Mail list logo
