--- Comment #1 from arcangelpip at hotmail dot com 2007-03-20 07:18 ---
Created an attachment (id=13237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13237&action=view)
Preprocessed output from the file.
Added the preprocessed output.
--
http://gcc.gnu.org/bugzilla/show_bug.
msgl-check.c: In function 'plural_help':
msgl-check.c:194: error: unrecognizable insn:
(insn 41 40 42 4 msgl-check.c:179 (set (reg:SI 75)
(const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i.plural_table") ) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
msgl-check.c:194: i
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-20 06:40 ---
Related to PR 26534.
Anyways the bug is in the front-end, We most likely have a mismatch type also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 06:34 ---
Related to PR 20115. Though in this case we only get VUSE as all the variables
listed are really const which is why if you add a function which sets
for_stack_ptr, it works as for_stack_ptr is no longer const.
This
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 06:17 ---
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 |blocker
Keywords||rejects-valid
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-20 05:54 ---
Closing again, this time as won't fix. Fortran is not C/C++/Java. This case
if you get -fbounds-check failing, then the bug is in the code and not in
Gfortran. Yes the standard might allow for short circuiting but
--- Comment #15 from spark at gcc dot gnu dot org 2007-03-20 04:50 ---
Fixed in 4.1, 4.2 and 4.3
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from spark at gcc dot gnu dot org 2007-03-20 04:45 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 04:45:14 2007
New Revision: 123083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123083
Log:
2007-03-19 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
--- Comment #3 from kargl at gcc dot gnu dot org 2007-03-20 03:09 ---
Tobi, this is a bogus request and the PR should be
closed. The standard does not require left to right
evaluation. It is the responsibility of the programmer
to know what she is doing. I think this should be
closed
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-03-20 02:20
---
Error 5001 would be ERROR_OPTION_CONFLICT. There are 18 different errors
associated with that code. To find out which one, you must remove the iostat
from the offending line so that gfortran will print the erro
de 2007-03-19 22:59 ---
> (In reply to comment #19)
>
> Jerry,
>
> I tried FX's snapshot from today (20070319) and the example
> above works. A somewhat more twisted example which I have
> not yet been able to reduce leads to an IOSTAT value of 5001
> (BTW: what
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-20 00:44
---
I think we can do the option case fairly straight forward, after we get some of
the more serious problems fixed. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-03-20 00:41
---
Reply to comment #8: that was my take on this, that ifort is correct. It
passed my intuitive sense of it. Non-advancing means what it says so that the
subsequent write must continue from there and overwrite what
--- Comment #3 from TabonyEE at austin dot rr dot com 2007-03-20 00:39
---
C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 00:24 ---
> D.1879_8 was replaced by 31, ignoring the fact that the value should have been
> truncated to 15 when assigned to s.b4.
The front-end should have truncated that to 15. Which front-end are you using,
C or C++?
-
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 23:52 ---
Created an attachment (id=13236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13236&action=view)
proposed cp/call.c patch for suspected standard_conversion bug
This is the proposed patch I referred to in my an
--- Comment #1 from wilson at gcc dot gnu dot org 2007-03-19 23:49 ---
I'm not a C++ expert, so I'm not the right person to say for sure, but this
looks like an accidental bug to me. There were patches added to change the
bitfield type representation, the is_bitfield_expr_with_lowered_t
--- Comment #17 from pcarlini at suse dot de 2007-03-19 23:43 ---
WONTFIX is simply ridicolous.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #16 from gdr at cs dot tamu dot edu 2007-03-19 23:40 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| But the user can see the code,
Andrew --
When you don't understand an issue, ple
--- Comment #15 from manu at gcc dot gnu dot org 2007-03-19 23:35 ---
Andrew, you have Paolo and Gabriel expressing that the warning should not be
emitted because the code is generated. Then you close as wontfix. Sometimes I
don't understand you at all.
--
http://gcc.gnu.org/bugzill
--- Comment #13 from jakub at gcc dot gnu dot org 2007-03-19 23:28 ---
Subject: Bug 30762
Author: jakub
Date: Mon Mar 19 23:28:33 2007
New Revision: 123075
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123075
Log:
PR c/30762
* c-typeck.c (convert_for_assignment)
--- Comment #8 from jakub at gcc dot gnu dot org 2007-03-19 23:27 ---
Subject: Bug 30505
Author: jakub
Date: Mon Mar 19 23:27:34 2007
New Revision: 123074
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123074
Log:
PR inline-asm/30505
* reload1.c (reload): Do inva
--- Comment #12 from jakub at gcc dot gnu dot org 2007-03-19 23:26 ---
Subject: Bug 30762
Author: jakub
Date: Mon Mar 19 23:26:14 2007
New Revision: 123073
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123073
Log:
PR c/30762
* c-typeck.c (convert_for_assignment)
--- Comment #7 from jakub at gcc dot gnu dot org 2007-03-19 23:24 ---
Subject: Bug 30505
Author: jakub
Date: Mon Mar 19 23:24:43 2007
New Revision: 123072
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123072
Log:
PR inline-asm/30505
* reload1.c (reload): Do inva
--- Comment #1 from TabonyEE at austin dot rr dot com 2007-03-19 23:19
---
GCC 4.1.2 returns 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-19 23:18
---
But the user can see the code, it is what is produced by what the C++ standard
says is produced, now you could say the user has no control over fixing it, it
is also true with the template case. Both cases are har
--- Comment #13 from manu at gcc dot gnu dot org 2007-03-19 23:13 ---
Andrew, as you say, -Wunreachable-code is not enabled by -Wall. The user has to
give it explicitly. And in your testcases the code is not reachable. So in that
case, it could be argued whether the warning is warranted
Using built-in specs.
Target: arm-elf
Configured with: /mnt/Sources/GCC/gcc_4/configure --prefix=/opt/arm
--target=arm-elf --enable-interwork --enable-multilib --enable-languages=c
Thread model: single
gcc version 4.1.3 20070319 (prerelease)
$ gcc-4.1.2 -v
Using built-in specs.
Target: x86_64-unkno
The following code compiles fine in GCC 4.1.
enum E { e };
struct S {
E v:5;
};
S s;
int main() { if (!s.v) return 0; }
In 4.2 (20070307), it gives the following error:
test.cpp: In function 'int main()':
test02.cpp:6: error: coul
--- Comment #20 from anlauf at gmx dot de 2007-03-19 22:59 ---
(In reply to comment #19)
Jerry,
I tried FX's snapshot from today (20070319) and the example
above works. A somewhat more twisted example which I have
not yet been able to reduce leads to an IOSTAT value of 5001
--- Comment #12 from gdr at cs dot tamu dot edu 2007-03-19 22:45 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #10)
| >
| > I fully agree.
|
| I am not agreeing fully,
Well
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #10)
| >
| > I fully agree.
|
| I am not agreeing fully,
Well, you've got a problem.
[...]
| What about this case:
There is a distinction betwen user code and compiler-generated codes.
Warning about compiler-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 22:44 ---
This is most likely super block formation happening way too late to be able to
optimize these calls.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
ret
.L12:
movl $1,%r0
ret
.L13:
cmpl %r1,$127
jeql .L14
xorb2 $1,%r0
movzbl %r0,%r0
ret
.L14:
movb $1,%r0
xorb2 $1,%r0
movzbl %r0,%r0
ret
.size in_canforward, .-in_canforward
.ident &quo
--- Comment #29 from sje at cup dot hp dot com 2007-03-19 22:41 ---
In reply to comment #28: I suspected as much but it is interesting that I have
a new gmp/mpfr. If I build bootstrap the resulting compiler passes these
tests. If I build non-bootstrap the resulting compiler does not p
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-19 22:31
---
(In reply to comment #10)
>
> I fully agree.
I am not agreeing fully, This warning is only because we can prove something
is pure/const/cannot throw and that only comes because of simple optimization.
What abou
The following shows a missing easy optimization for GCC:
int
in_canforward(unsigned int in)
{
if ((in & ~0xff0f) == 0xf0 || (in & ~0xff0f) == 0xe0)
return 0;
return 1;
}
results in (@ -O2):
in_canforward:
andl$240, %edi
cmpl$240, %e
For the code
program xcheck
implicit none
integer :: i,ivec(2)
ivec = 0
do i=1,3
if (i**2 < 10) print*,ivec(i)
end do
end program xcheck
gfortran -Wall -fbounds-check
for mingw 4.3.0 20070315
gives at run time
Fortran runtime error: Array reference out of bounds for array 'ivec', upper
boun
--- Comment #3 from vivekrao4 at yahoo dot com 2007-03-19 21:55 ---
I agree with comments #1 and #2 that minimal width and fixed width
list-directed I/O can be useful, and I don't think gfortran should change its
default list-directed output, because some people may be relying, unwisely
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 21:32 ---
In theory, obstack.h is imported from the FSF gnulib package, though
unfortunately that isn't documented in our codingconventions.html web page, and
it looks like people have just been modifying it in place. The pare
Eric Lemings wrote:
Is this a bug or new behavior? If the latter, what is this attributed
to?
FYI gcc-bugs isn't the best place to ask questions, as it is mostly used
for output from our bug database.
I'm not a C++ expert, so I'm not the right person to say for sure, but
this looks like an
--- Comment #11 from law at gcc dot gnu dot org 2007-03-19 20:04 ---
Subject: Bug 30984
Author: law
Date: Mon Mar 19 20:04:04 2007
New Revision: 123069
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123069
Log:
2007-03-19 Jeff Law <[EMAIL PROTECTED]>
* tree-cfg.c (fin
--- Comment #10 from law at redhat dot com 2007-03-19 20:04 ---
Fix committed to mainline, gcc-4.1 and gcc-4.2 branches
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
--- Comment #9 from law at gcc dot gnu dot org 2007-03-19 20:03 ---
Subject: Bug 30984
Author: law
Date: Mon Mar 19 20:03:07 2007
New Revision: 123068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123068
Log:
2007-03-19 Jeff Law <[EMAIL PROTECTED]>
* tree-cfg.c (find
Mo DeJong wrote:
long val2 = 1; /* incorrect warn when val2 is a long */
int c2 = (
((long long) val2) <
((long long)(-2147483647L - 1))
);
The result of the compare will always be false, so the warning is correct.
The long variable val2 can not hold a value sma
--- Comment #8 from law at gcc dot gnu dot org 2007-03-19 19:52 ---
Subject: Bug 30984
Author: law
Date: Mon Mar 19 19:52:19 2007
New Revision: 123067
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123067
Log:
* tree-cfg.c (find_taken_edge): Tighten conditions for
--- Comment #7 from law at redhat dot com 2007-03-19 19:52 ---
Fixed with today's patch to tree-cfg.c.
--
law at redhat dot com changed:
What|Removed |Added
S
--- Comment #6 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
19:37 ---
Created an attachment (id=13235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13235&action=view)
pre-processed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
--- Comment #6 from fang at csl dot cornell dot edu 2007-03-19 18:51
---
Subject: Re: std::valarray should be annotated with
OpenMP directives
> "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
>
> | (In reply to comment #3)
> | > I suspect that parallelizing for SSE/Altivec
--- Comment #6 from pinskia at gmail dot com 2007-03-19 17:52 ---
Subject: Re: pseudo-optimzation with sincos/cexpi
On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
>
> Since sin() and cos() are non trivial functions, I am very surprised
> that a
On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
Since sin() and cos() are non trivial functions, I am very surprised
that a wrong API makes a 50% difference.
Well Here is how it can make a 50% difference (at least on the Cell,
the 970 has less of a restr
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-19 17:37 ---
I'm not going to dig through the standard again to dig out the precise wording,
but as long as one doesn't actually access the out-of-bound array element the
program is valid. Furthermore, the standard allows short-cir
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 17:24 ---
As mentioned before, this is not really a bug as the fortran says .and. is not
short circuiting.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
program toto
implicit none
real:: a(10)
integer :: i
a(:) = 1.
do i=1,100
if( i <= 10 .and. a(i) > 0. ) write(*,*) i,a(i)
enddo
end
Compiling this program with -fbounds-check will give an out-of-bound error
because the bound checking happens before the evaluation of the expression.
As
--- Comment #5 from kristerw at gcc dot gnu dot org 2007-03-19 17:08
---
Subject: Bug 30058
Author: kristerw
Date: Mon Mar 19 17:08:14 2007
New Revision: 123065
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123065
Log:
2007-03-18 Krister Walfridsson <[EMAIL PROTECTED]>
--- Comment #5 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
16:55 ---
Subject: Re: Non-deterministic bug producing a run-time infinite
loop
Let me try to attach the pre-processed file through an email
attachement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=312
--- Comment #4 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
16:50 ---
(sorry I still can't create attachments)
-ftrapw makes the program work (no loop).
Let me copy-paste here the non-preprocessed source files which show everything
which is executed, while waiting for b
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-19 16:47 ---
On x86 different addressing modes and induction variables are used. Good:
.L2:
movq%r12, 8(%rsp)
addl$1, %ebp
movsd 8(%rsp), %xmm0
callSquare
movsd %xmm0, (%r
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-19 16:45 ---
(In reply to comment #2)
> Just wild guessing - try -fwrapv.
Well it already does not look for -fno-strict-aliasing so I am assuming an
aliasing bug in your code until you provide the sources.
--
pinskia at gcc
--- Comment #28 from ghazi at gcc dot gnu dot org 2007-03-19 16:41 ---
(In reply to comment #27)
> I did a non-bootstrap build and test on hppa1.1-hp-hpux11.11 over the weekend
> (C only) and I got two failures that I don't normally see,
> builtin-pow-mpfr-1.c
> and builtin-sin-mpfr-1.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-19 16:32 ---
Just wild guessing - try -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
--- Comment #5 from aph at gcc dot gnu dot org 2007-03-19 16:30 ---
Created an attachment (id=13234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13234&action=view)
.class file
Compile this with gcc/trunk/install/bin/gcj MathLib.class -c -O2
--
aph at gcc dot gnu dot org chan
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
16:27 ---
I will happily create the attachements when bugzilla will work...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
It took me several hours to try to extract a usable test-case for this issue,
so I hope you will be able to make sense out of it.
The problem : compiling with current g++ 4.2, with -O2, makes the attached
program loop infinitely, while it is not expected to.
It does not loop with g++ 4.3 or older
--- Comment #27 from sje at cup dot hp dot com 2007-03-19 16:11 ---
I did a non-bootstrap build and test on hppa1.1-hp-hpux11.11 over the weekend
(C only) and I got two failures that I don't normally see, builtin-pow-mpfr-1.c
and builtin-sin-mpfr-1.c. I am not certain these failures are
This wrong code (missing typename):
template
struct A
{
typedef typename T::B C;
void f(C::D x);
};
gives the following error message:
a.cpp:5: error: '#'typename_type' not supported by dump_decl#::D' is not a type
instead of "'C::D' is not a type".
--
Summary: #
--- Comment #4 from aph at gcc dot gnu dot org 2007-03-19 15:57 ---
Created an attachment (id=13233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13233&action=view)
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
--- Comment #3 from aph at gcc dot gnu dot org 2007-03-19 15:53 ---
Created an attachment (id=13232)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13232&action=view)
Failing routine
A stripped-down test case that demonstrates the failure.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-19 15:47 ---
On the trunk, there is no difference in the assembly produced for PPC-darwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When a component of a "custom" type is a character, taking a substring of it
triggers a warning about the variable being truncated (with -Wall). Maybe it is
not the correct syntax to get a substring out of a character component (still,
it works fine for printing, for example)?
$cat test.f90
PROGR
With std f95 or f2003, "reshape" is not allowed in real arrays, but it is in
integer ones or with std legacy or gnu.
It seems the standard should actually allow this construct (see
http://gcc.gnu.org/ml/fortran/2007-02/msg1.html), so here is a bug report
(I didn't anything similar).
$cat tes
--- Comment #12 from jakub at gcc dot gnu dot org 2007-03-19 15:27 ---
This fix causes PR30505 regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
--- Comment #6 from jakub at gcc dot gnu dot org 2007-03-19 15:26 ---
Caused by PR21299 patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gdr at cs dot tamu dot edu 2007-03-19 15:23 ---
Subject: Re: std::valarray should be annotated with OpenMP directives
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #3)
| > I suspect that parallelizing for SSE/Altivec might be more
--- Comment #10 from gdr at cs dot tamu dot edu 2007-03-19 15:19 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| And I think that we should not warn about generated code. No matter if it is
| generated
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from membar at gcc dot gnu dot org 2007-03-19 14:44 ---
Created an attachment (id=13231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13231&action=view)
temps file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
--- Comment #1 from membar at gcc dot gnu dot org 2007-03-19 14:43 ---
Created an attachment (id=13230)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13230&action=view)
javolution.jar (BSD license)
source & distribution from http://www.javolution.org/
--
http://gcc.gnu.org/bu
imac20:/tmp/javolution mohanembar$ i686-apple-darwin8-gcj -v -save-temps -c -O2
javolution.jar
Using built-in specs.
Reading specs from
/datal/gcc/i686-apple-darwin8/bin/../lib/gcc/i686-apple-darwin8/4.3.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target
--- Comment #4 from bangerth at dealii dot org 2007-03-19 14:03 ---
(In reply to comment #3)
> I suspect that parallelizing for SSE/Altivec might be more peneficial
> in most cases than for OpenMP -- OpenMP is a 1,000 pounds gorilla.
I certainly agree. The beauty is that one may have bo
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-19 13:56 ---
(In reply to comment #8)
> >I agree with you Paolo. The front-end should make sure that its
> > artefacts don't adversily affect diagnostics we emit.
>
> I agree to some extend. The reason why the try/catch is there
I'm not sure, if this can be called a bug, but it is at least a really bad case
of poor optimization.
The following program calls the function 'Square' several times, either with
x=1000 or x=i*2-i-i+1000 (which is also 1000). The second version is executed
much FASTER. I see no reason, why this sh
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-03-19 13:37
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-19 13:36
---
Subject: Bug 31254
Author: rguenth
Date: Mon Mar 19 13:36:29 2007
New Revision: 123060
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123060
Log:
2007-03-19 Andrew Pinski <[EMAIL PROTECTED]>
Rich
--- Comment #6 from mueller at gcc dot gnu dot org 2007-03-19 13:21 ---
it seems to be caused by -r121780
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30864
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-19 12:53 ---
Reading further, I find:
"For nonadvancing input [...] If no error condition occurred in a nonadvancing
output statement, the file position is not changed."
If I understand the whole correctly, it means:
- The positi
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-19 12:43 ---
> There is no option to turn it off. But for !TARGET_C99_FUNCTIONS and
> !TARGET_HAS_SINCOS targets it's off.
>From my understanding of the thread
http://gcc.gnu.org/ml/gcc/2007-03/msg00639.html
if !TARGET_64BIT
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-19 12:40 ---
Subject: Re: std::valarray should be annotated with OpenMP directives
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
|
| Wolfgang: I agree. We should have also parallelized this for SSE/Altivec a la
| MacS
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-19 12:24
---
This is mine, I'm deep into these things right now :(
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
$ cat uu.f90
print *, 7_8*huge(0_8)+17_8
end
$ gfortran -static uu.f90 -fno-range-check
uu.f90: In function MAIN__:
uu.f90:1: internal compiler error: in gfc_conv_mpz_to_tree, at
fortran/trans-const.c:183
There's an assertion in gfc_conv_mpz_to_tree:
/* We assume that all numbers are
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-19 12:18 ---
> You can probably add xlf to this list
and Portland Group Fortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
--- Comment #6 from dominiq at lps dot ens dot fr 2007-03-19 12:15 ---
> Result by g95/ifort:
You can probably add xlf to this list (should be checked
on a recent version).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-03-19 11:37 ---
Fixed
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-03-19 11:35 ---
Wolfgang: I agree. We should have also parallelized this for SSE/Altivec a la
MacSTL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31000
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-19 11:19 ---
You would need to enhance associate_trees () or the reassoc pass to fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
1 - 100 of 123 matches
Mail list logo
