--- Comment #6 from uros at kss-loka dot si 2005-11-15 08:13 ---
Perhaps a runtime check should be added to target-supports.exp
( check_effective_target_tls-runtime perhaps) that would check if the system is
capable of running tls enabled binaries. Alternatively, my proposed patch
(http:
Running make check in fixincludes on x86_64-gnu-linux I get the
following failure:
Fixed: Xm/Traversal.h
cmp: EOF on string.h
*** string.h2005-11-10 12:25:31.0 +0100
--- /cvs/gcc-svn/trunk/fixincludes/tests/base/string.h 2005-11-10
12:23:56.0 +0100
***
*** 10,13 *
--- Comment #1 from aj at gcc dot gnu dot org 2005-11-15 08:14 ---
Jim Wilson commented in http://gcc.gnu.org/ml/gcc/2005-11/msg00619.html:
Just grepping for "_STRING_INCLUDED" it is easy to see the input rule
in inclhack.def that defines this transformation, and the output rule
in fixi
--- Comment #21 from debian-gcc at lists dot debian dot org 2005-11-15
08:28 ---
(In reply to comment #20)
> Could people check if the problem was indeed fixed where reported?
bootstrap ok on alpha-linux
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-15 08:59 ---
The problem here is a mismatch between determine_parallel_type in gimplify.c
and omp-low.c. During gimplification, it is not considered to be a combined
parallel loop, because OMP_PARALLEL's body contains a DECL_EXPR
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 09:07
---
Some more information:
- I didn't encounter the bug about a week ago
- on x86_64 with checking disabled, I get
[EMAIL PROTECTED]:~/martin> g++ -c -v -fopenmp test.cc
Using built-in specs.
Target: x86_64-unk
--- Comment #7 from joseph at codesourcery dot com 2005-11-15 09:23 ---
Subject: Re: gcc.dg/tls/pr24428.c execution test and
gcc.dg/tls/pr24428-2.c execution test fail on IA32
On Tue, 15 Nov 2005, uros at kss-loka dot si wrote:
> The job of compiler is IMO to compile sources correctl
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #3 from debian-gcc at lists dot debian dot org 2005-11-15
10:50 ---
(In reply to comment #2)
> I'll take care of it.
>
> Arno
can this be updated before the branch is created?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
--- Comment #1 from hp at gcc dot gnu dot org 2005-11-15 10:52 ---
Subject: Bug 24869
Author: hp
Date: Tue Nov 15 10:52:06 2005
New Revision: 106946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106946
Log:
PR target/24869
* config/cris/cris.md ("*mov_sidesisf_m
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-15 10:56 ---
Fixed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01055.html>.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
i bootstrap gcc 4.0.2 on AIX 5.2,i got the error message as follows:
-
Bootstrap comparison failure!
./fold-const.o differs
make[1]: *** [slowcompare] Error 1
make[1]: Leaving directory `/swtdata/emv_emu/emu1/jbgao/objdir/gcc'
make: *** [bootstrap] Error 2
--
i used gnu make already.
is t
--- Comment #4 from charlet at adacore dot com 2005-11-15 11:04 ---
Subject: Re: [ada] Library_Version still at 4.0 ?
> can this be updated before the branch is created?
Will commit the patch later today or tomorrow.
Arno
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
--- Comment #5 from pluto at agmk dot net 2005-11-15 11:16 ---
what about soext in gcc41/gcc/ada/Makefile.in?
there is still soext = .so
is ada abi compatible in gcc 3.3 ... 4.1 ?
--
pluto at agmk dot net changed:
What|Removed |Added
-
--- Comment #6 from charlet at adacore dot com 2005-11-15 11:22 ---
Subject: Re: [ada] Library_Version still at 4.0 ?
> what about soext in gcc41/gcc/ada/Makefile.in?
> there is still soext = .so
> is ada abi compatible in gcc 3.3 ... 4.1 ?
You seem to be confused: soext is about the
--- Comment #7 from debian-gcc at lists dot debian dot org 2005-11-15
11:42 ---
PR23750 is related
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
--- Comment #3 from pcarlini at suse dot de 2005-11-15 12:02 ---
> 2- Otherwise, a lock in _M_reclaim_block only when __block->_M_thread_id !=
>__thread_id. At the same time has to be changed _M_reserve_block too,
>however, and it's tricky to do that without locking at every sing
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-11-15 12:14
---
(In reply to comment #7)
> We should bump the library file's version number.
Could we get a gcc-admin script to change the library's version everyday with
version numbers like 0.0.20051115 and so on?
--
http
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:20 ---
It would be useful to to either have separate bugs for these issues, or to list
them all in the audit trail of this bug. Without more information, this bug
does not contain much information, it's more like an FYI ins
--- Comment #4 from l_heldt at poczta dot onet dot pl 2005-11-15 12:26
---
Unfortunately I cannot perform such test because it would require changing
stdlibc++ on many machines.
My solution to this problem is setting GLIBCXX_FORCE_NEW variable before
starting application.
--
http:
--- Comment #5 from pcarlini at suse dot de 2005-11-15 12:31 ---
(In reply to comment #4)
> Unfortunately I cannot perform such test because it would require changing
> stdlibc++ on many machines.
Out of curiosity: why many and not just one (and optionally, of course, along
the existing
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-15 12:31
---
(In reply to comment #6)
> 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.
You should really attach
g++ -g ManuProcEntity.ii
ManuProcEntity.cc:35: internal compiler error: in add_AT_specification, at
dwarf2out.c:4903
omitting -g makes the compilation work.
--
Summary: ICE: in add_AT_specification, at dwarf2out.c:4903
Product: gcc
Version: 4.0.2
St
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-15 12:51 ---
As a work-around, configure with --disable-libmudflap, you don't need that
library anyway, it is an instrumentation library for memory access violations
for C and C++, so you don't need it for gfortran.
--
steven
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:53 ---
Note that we would still like to know what target you are configuring for. If
you can copy-and-paste the first, say, 10 lines of output from your configure,
that would be most helpful.
--
steven at gcc dot gnu do
--- Comment #1 from christof at petig-baender dot de 2005-11-15 12:53
---
Created an attachment (id=10243)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10243&action=view)
the failing program (ManuProcEntity.ii.gz)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
ata/martin/mygmp
Thread model: posix
gcc version 4.1.0 20051115 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 huge.f90
-quiet -dumpbase huge.f90 -mtune=pentiumpro -auxbase huge -version -o
/tmp/ccjkyE0d.s
GNU F95 version 4.1.0 20051115 (experimental) (i686-pc-li
--
uros at kss-loka dot si changed:
What|Removed |Added
CC|uros at kss-loka dot si |
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
--- Comment #22 from charlet at gcc dot gnu dot org 2005-11-15 13:51
---
Subject: Bug 18434
Author: charlet
Date: Tue Nov 15 13:51:09 2005
New Revision: 106950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106950
Log:
2005-11-14 Robert Dewar <[EMAIL PROTECTED]>
E
--- Comment #8 from charlet at gcc dot gnu dot org 2005-11-15 13:59 ---
Subject: Bug 23732
Author: charlet
Date: Tue Nov 15 13:59:02 2005
New Revision: 106980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106980
Log:
PR ada/23732
* gnatvsn.ads (Library_Version):
--- Comment #3 from charlet at gcc dot gnu dot org 2005-11-15 14:04 ---
Subject: Bug 15604
Author: charlet
Date: Tue Nov 15 14:03:56 2005
New Revision: 107006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107006
Log:
2005-11-14 Ed Schonberg <[EMAIL PROTECTED]>
Jav
--- Comment #23 from charlet at gcc dot gnu dot org 2005-11-15 14:08
---
Fixed.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|W
--- Comment #9 from charlet at gcc dot gnu dot org 2005-11-15 14:09 ---
Fixed.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from charlet at gcc dot gnu dot org 2005-11-15 14:10 ---
Fixed.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #15 from rakdver at gcc dot gnu dot org 2005-11-15 14:27
---
Subject: Bug 24762
Author: rakdver
Date: Tue Nov 15 14:27:48 2005
New Revision: 107017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107017
Log:
PR rtl-optimization/24762
* except.c (dw2_b
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 15:15 ---
*** This bug has been marked as a duplicate of 23400 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-15 15:15 ---
*** Bug 24870 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 15:22 ---
I think this is a dup of bug 24569 which was fixed for 4.0.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-15 15:38
---
(In reply to comment #12)
> specify --with-local-prefix=/opt/OPSWbuildtools/1.0.1
> Am I missing something?
Yes it sounds like it is picking up the wrong header otherwise.
--
pinskia at gcc dot gnu dot org cha
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-15 15:38
---
(In reply to comment #13)
> (In reply to comment #12)
> > specify --with-local-prefix=/opt/OPSWbuildtools/1.0.1
> > Am I missing something?
> Yes it sounds like it is picking up the wrong header otherwise.
s/heade
--- Comment #5 from trt at acm dot org 2005-11-15 15:43 ---
Since fold() is increasingly used for internal speculative computations, I
think it should avoid issuing warnings as false positives are too likely. So
perhaps this warning belongs in parser_build_binary_op() in c-typeck.c
Sim
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-15 16:19 ---
(In reply to comment #1)
> "1000" is a signed integer constant, so b*1000 is a signed integer too. I
> guess the warning is ok, then.
That is only true for unsigned multiplication and signed when overflow is
undefin
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-15 16:24 ---
The orginal testcase was fixed for 4.0.0 by:
2005-01-23 Steven Bosscher <[EMAIL PROTECTED]>
PR rtl-optimization/19464
* tree-optimize.c (init_tree_optimization_passes): Add one more
copyren
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-15 16:31
---
Hold on, in C99, complex is a scaler type so libstdc++ is using a GCC extension
over what C99 requires which causes this.
And my comment in #6 still holds for this bug. I think libstdc++ should
rethink about this
--- Comment #11 from pcarlini at suse dot de 2005-11-15 16:39 ---
(In reply to comment #10)
> And my comment in #6 still holds for this bug. I think libstdc++ should
> rethink about this.
libstdc++ can rething anything, in principle, but if you change the component
to libstdc++, nobody
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-15 16:47
---
(In reply to comment #9)
> Certainly, the test-case in Comment #1 does depend on libstdc++ at all.
> Let's fix this.
The testcase in comment #1 shows the issue with what libstdc++ is doing. Since
complex is sca
--- Comment #5 from krebbel at gcc dot gnu dot org 2005-11-15 16:47 ---
The only difference my patch brought is different behaviour
of mark_set_1 if it is called under wrong! conditions. Will
say that only in case somebody calls mark_set_1 clobbering a reg which
is live afterwards - we
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2005-11-15 16:55
---
It's nice to see that PR bouncing between you all. Although I don't know
anything about C++, I want to add my non-constructive comment to this
discussion: I don't understand how a bug which has a C-only testcase
--- Comment #24 from olle at cb dot uu dot se 2005-11-15 17:27 ---
(In reply to comment #20)
> Could people check if the problem was indeed fixed where reported?
I did try the new suggested fix on tru64 5.1B on an Alpha. It gets past the
previous error pointb ut it fails later on while
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-11-15 17:44
---
Subject: Bug 24687
Author: mmitchel
Date: Tue Nov 15 17:44:28 2005
New Revision: 107030
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107030
Log:
PR c++/24687
* g++.dg/template/crash43.C:
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-11-15 17:50
---
Subject: Bug 24667
Author: mmitchel
Date: Tue Nov 15 17:50:43 2005
New Revision: 107031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107031
Log:
PR c++/24667
* typeck.c (check_for_casting
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-15 17:52
---
Subject: Bug 24667
Author: mmitchel
Date: Tue Nov 15 17:52:34 2005
New Revision: 107032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107032
Log:
PR c++/24667
* typeck.c (check_for_casting
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-15 17:57
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #28 from uweigand at gcc dot gnu dot org 2005-11-15 18:31
---
Just one additional comment: the patch from comment #10 was rejected,
maybe because it required changes to the core gimplifier.
However, I've tested just the Ada front-end pieces from that patch,
and this *alread
This test is taken from, http://ftp.cac.psu.edu/pub/ger/fortran/test/test10.for
$ cat test.f90
INTEGER X, Y, SUBA
EXTERNAL SUBA
X=-1
Y=-2
CALL ANY(SUBA,X,Y)
WRITE(*,*)'Did NOT catch this error'
PAUSE
STOP
END
SUBROUTIN
--- Comment #9 from daney at gcc dot gnu dot org 2005-11-15 19:11 ---
Subject: Bug 15430
Author: daney
Date: Tue Nov 15 19:11:53 2005
New Revision: 107036
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107036
Log:
PR libgcj/15430
* gnu/java/net/natPlainSocketImpl
It seems that SSE3 _mm_monitor instrinsic doesn't work too well with
64bit.
[EMAIL PROTECTED] function]$ cat x.c
#include
#include
static void
foo (char *p)
{
_mm_monitor(p, 0, 0);
}
main()
{
char *p = (char *)&foo;
int fail = 1;
int i;
for (i = 0; i < 20; i++) {
if
--- Comment #17 from reichelt at gcc dot gnu dot org 2005-11-15 19:14
---
Subject: Bug 22172
Author: reichelt
Date: Tue Nov 15 19:14:21 2005
New Revision: 107037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107037
Log:
PR c++/19253
PR c++/22172
Backpor
--- Comment #15 from reichelt at gcc dot gnu dot org 2005-11-15 19:14
---
Subject: Bug 19253
Author: reichelt
Date: Tue Nov 15 19:14:21 2005
New Revision: 107037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107037
Log:
PR c++/19253
PR c++/22172
Backpor
--- Comment #10 from daney at gcc dot gnu dot org 2005-11-15 19:16 ---
Fixed by committed patch.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-15 19:17 ---
Confirmed and not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from reichelt at gcc dot gnu dot org 2005-11-15 19:18
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-15 19:19
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-11-15 19:23
---
There is nothing wrong with the code in Comment #1; __imag__ is an
lvalue-yielding operator. If, for some reason, we wanted to make __imag__
yield an rvalue, then this code would be rejected with an error; under
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 19:24 ---
(define_insn "sse3_mwait"
[(unspec_volatile [(match_operand:SI 0 "register_operand" "a")
(match_operand:SI 1 "register_operand" "c")]
UNSPECV_MWAIT)]
"TARGET_SSE3"
"mwai
--- Comment #25 from olle at cb dot uu dot se 2005-11-15 19:27 ---
(In reply to comment #24)
Seems that the basic difference between the working case (the preliminary
work around) and the final fix is that
in the working case there are two occasions of "-L./" in the linking command
in
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-15 19:34 ---
A regression hunt identified the following patch from Janne Blomqvist:
http://gcc.gnu.org/viewcvs?view=rev&rev=104662
r104662 | bdavis | 2005-09-26 20:24:45 + (Mon, 26 Sep 2005) | 28 lines
--
janis at gcc dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-15 19:45 ---
Confirmed, but minor since a lot of the other fortran implemenations don't
detect it either.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Explicit conversion from a numeric integer Type to Integer causes a crash of
gcc
when the type is defined with a Size representation clause.
The bug disappears if the representation clause is removed or
if the range begins with 0.
Environment:
System: Linux simone 2.6.12.051101 #1 Tue Nov 1 17:19
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-15 20:11 ---
The code works for me on amd64-*-freebsd. Can
you compile the failing code with -fdump-parse-tree
and post both mod1.mod and the parse-tree?
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-15 20:16 ---
It fails on powerpc64-linux with both -m32 and -m64 for current trunk,
4.0 branch, and GCC 4.0.0. Since it's Fortran 90 code it's not really
a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
--- Comment #2 from laurent at guerby dot net 2005-11-15 20:22 ---
Confirmed on x86_64-linux and x86-linux. On x86 svn 4.0.3 and 4.1 gnat1 grows
memory above 1GB and I had to kill the processes. 3.3.5 does not have the
issue. On x86_64 gnat1 segfault immediately.
--
laurent at guerby
--- Comment #2 from amodra at gcc dot gnu dot org 2005-11-15 20:33 ---
Subject: Bug 24096
Author: amodra
Date: Tue Nov 15 20:33:48 2005
New Revision: 107041
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107041
Log:
PR fortran/24096
* trans-types.c (gfc_init_kind
--- Comment #3 from amodra at bigpond dot net dot au 2005-11-15 20:35
---
Fixed mainline.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
St
This is to track this proposal for enhancement:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00184.html
--
Summary: Lazy facet instantiation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
--- Comment #9 from drow at gcc dot gnu dot org 2005-11-15 20:58 ---
Subject: Re: [4.1 regression] invalid register in debug info
On Thu, Oct 20, 2005 at 08:35:59AM -, rth at gcc dot gnu dot org wrote:
> Well, the ideal fix is to make use of the dwarf3 DW_OP_call_frame_cfa
> direct
This meta-bug tracks work on a new, ABI-breaking, basic_string implementation.
Currently, we have refactored code in v7-branch which includes two alternative
base classes: one doesn't use reference counting, is optimized for short
strings and includes (simulated) move constructor and assignment ope
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
--- Comment #5 from pcarlini at suse dot de 2005-11-15 21:07 ---
This PR can now be closed, basing on up to date comments from John David Anglin
([EMAIL PROTECTED]), which indicate that now shared versions of libgcc
are
built on both 32 and 64-bit ports. He also remarks that "it's techni
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09
---
(In reply to comment #2)
> It fails on powerpc64-linux with both -m32 and -m64 for current trunk,
> 4.0 branch, and GCC 4.0.0. Since it's Fortran 90 code it's not really
> a regression.
Well, it worked for
--- Comment #4 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09
---
> The code works for me on amd64-*-freebsd. Can
> you compile the failing code with -fdump-parse-tree
> and post both mod1.mod and the parse-tree?
Will do tomorrow.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #5 from martin at mpa-garching dot mpg dot de 2005-11-15 21:16
---
~/tmp>gfortran -c -fdump-parse-tree huge.f90
Namespace: A-Z: (UNKNOWN 0)
procedure name = mod1
symtree: gndp_max Ambig 0
symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INTENT UNK
--- Comment #15 from tedoc2000 at gmail dot com 2005-11-15 21:27 ---
Okay so it wasn't the --with-local-prefix.
It was the fact that I used --prefix=/opt/OPSWbuildtools/1.0.1.
If I use a directory that doesn't already exist then I get my desired results.
So that makes us ask. "Well what
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-15 21:42
---
(In reply to comment #14)
> There is nothing wrong with the code in Comment #1; __imag__ is an
> lvalue-yielding operator. If, for some reason, we wanted to make __imag__
> yield an rvalue, then this code would be
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2005-11-15 21:49 ---
Subject: Re: [gfortran, 4.1.0 regression] Arithmetic overflow during
compilation
> Comment #5 from martin
> ~/tmp>gfortran -c -fdump-parse-tree huge.f90
>
>Namespace: A-Z: (UNKNOWN 0)
>procedure
--- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-15 21:50
---
(In reply to comment #8)
> Will take a look shortly.
>
I stand by my analysis in #5. The Fortran FE is lying to the middle end.
There is no field 'ktbuf' in this structure.
--
dnovillo at gcc dot gnu dot org
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-15 21:51
---
Here is the current patch so for libstdc++ (I did not test it yet):
Index: include/std/std_complex.h
===
--- include/std/std_complex.h (revision 106
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-15 21:57
---
(In reply to comment #13)
> It's nice to see that PR bouncing between you all. Although I don't know
> anything about C++, I want to add my non-constructive comment to this
> discussion: I don't understand how a bu
--- Comment #18 from pcarlini at suse dot de 2005-11-15 22:00 ---
(In reply to comment #16)
> Here is the current patch so for libstdc++ (I did not test it yet):
Before patching this and that in the runtime library, don't you believe that:
1- If, as Mark said, (__imag__ t) is an lvalue,
/usr/lib/gcc/s390-suse-linux/4.1.0/cc1 -fpreprocessed reo.i -quiet -dumpbase
reo.i -m31 -mesa -march=g5 -ansi -auxbase reo -O2 -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wredundant-decls -Wnested-externs -Wundef -ansi -version -fomit-frame-pointer
-fno-st
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-15 22:03 ---
Created an attachment (id=10245)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10245&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-11-15 22:10
---
There are only two choices: either __imag__ is an lvalue, and the code in
Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
issue an error.
Nobody wants to see a warning about an uninitia
--- Comment #9 from et at ihear dot com 2005-11-15 22:10 ---
This cripples virtual inheritance for fine-grain parallel processing. There
should at least be a compiler option for process-independent referencing,
because admittedly, this would slow down dereferencing. Or maybe a operator n
This test is taken from
http://ftp.cac.psu.edu/pub/ger/fortran/test/
$ cat test.f90
MODULE all_sub
PRIVATE
PUBLIC :: test1,test2
CONTAINS
SUBROUTINE test1(a,n)
IMPLICIT NONE
INTEGER,INTENT(in) :: n
REAL,INTENT(out), DIMENSION(n) :: a
REAL :: b
WRITE(*,*) 'Problem with inte
--- Comment #20 from pcarlini at suse dot de 2005-11-15 22:16 ---
About the optimization issue, maybe we should file a separate enhancement PR,
if there isn't already one. Really, we should be able to optimize well any
variant of this kind of code.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #4 from dje at gcc dot gnu dot org 2005-11-15 22:27 ---
Patch
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #10 from pcarlini at suse dot de 2005-11-15 22:38 ---
To be sure we don't confuse two issues here (see also my #7), all the
containers
are already able to use shared memory allocators such as libmm:
http://www.ossp.org/pkg/lib/mm/
(via a very lightweight wrapper). This is
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-15 23:15 ---
Show me one compiler that catches this. HP doesn't, and Intel doesn't.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
Following code fails to report the runtime error. The program goes into
infinite loop.
$ cat test.f90
program modify_by_include
implicit none
integer i
do i = 1, 10
call dangerous_inclusion
write(*,'(a,i0)') ' i = ', i
end do
contains
subroutine dangerous_inclusi
1 - 100 of 114 matches
Mail list logo
