--- Comment #6 from reichelt at gcc dot gnu dot org 2007-12-11 08:03
---
Also crashes on x86_64-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
--- Comment #4 from uros at gcc dot gnu dot org 2007-12-11 08:08 ---
Subject: Bug 34407
Author: uros
Date: Tue Dec 11 08:08:12 2007
New Revision: 130769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130769
Log:
PR tree-optimization/34407
* gcc.dg/vect/pr34407.c:
--- Comment #5 from ubizjak at gmail dot com 2007-12-11 08:09 ---
Fixed in SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-11 08:20 ---
Subject: Bug 34364
Author: jakub
Date: Tue Dec 11 08:20:15 2007
New Revision: 130770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130770
Log:
PR c++/34364
* rtti.c (build_dynamic_cast): Call
--- Comment #9 from jakub at gcc dot gnu dot org 2007-12-11 08:22 ---
Subject: Bug 34238
Author: jakub
Date: Tue Dec 11 08:22:10 2007
New Revision: 130771
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130771
Log:
PR c++/34238
* decl2.c (cp_write_global_declarati
--- Comment #4 from jakub at gcc dot gnu dot org 2007-12-11 08:37 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|
--- Comment #10 from jakub at gcc dot gnu dot org 2007-12-11 08:39 ---
Fixed, at the expense of reverting PR34094 fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2007-12-11 08:41 ---
On Mark's request I have reverted this fix.
I'll attach a patch against trunk which errors in cases where ld would error.
--
jakub at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #14 from aldot at gcc dot gnu dot org 2007-12-11 08:46 ---
(In reply to comment #13)
> Just asking for status of this bug:
> Seems to be still valid with gcc-4.2.2 - don't (want to) have texinfo
> installed.
Please submit a tested patch along the lines of Mark's comment #8
--- Comment #10 from jakub at gcc dot gnu dot org 2007-12-11 08:48 ---
Created an attachment (id=14723)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14723&action=view)
gcc43-pr34094.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
--- Comment #11 from jakub at gcc dot gnu dot org 2007-12-11 08:48 ---
Unassigning myself.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-11 08:54 ---
Maybe it is valid. Richard Maine writes in the thread:
-- quote
It isn't allowed. But that restriction is in a different place (a much
more sensible one). [...]
For that one see 9.11 in f
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-12-11 09:51 ---
It works for me on "i386-apple-darwin8.10.1" with:
GNU C++ (GCC) version 4.3.0 20071209 (experimental) [trunk revision 130717]
(i386-apple-darwin8.10.1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
I believe the following program is valid; it is compiled by g95, ifort, NAG
f95, but gfortran rejects it with:
Error: Expression at (1) must be of INTEGER type
For the for KIND we had a similar problem, see
PR fortran/31154
PR fortran/31229
PR fortran/4
and PR 34
--- Comment #3 from oliver dot kellogg at eads dot com 2007-12-11 09:36
---
Still happens with 20071211 r130768.
BTW the workaround is to introduce a temporary variable (LICG) as follows:
package body mac6dw is
procedure Generate_Callforward is
MADR
--- Comment #28 from jakub at gcc dot gnu dot org 2007-12-11 10:02 ---
This smells dataflow related. At least if I understood right, the problem is
that the
_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT1_T2_St20forward_iterator_tag
function is calle
/usr/src/ark/BUILD/gcc-4.3.0/build/./prev-gcc/xgcc
-B/usr/src/ark/BUILD/gcc-4.3.0/build/./prev-gcc/ -B/usr/i586-ark-linux/bin/ -c
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-12-11 10:07
---
This is a bug in the delayed branch scheduler. Patch here:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00506.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34415
--- Comment #1 from bero at arklinux dot org 2007-12-11 10:10 ---
Created an attachment (id=14727)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14727&action=view)
fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34430
--- Comment #2 from phelps at gnusto dot com 2007-12-11 10:38 ---
Created an attachment (id=14728)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14728&action=view)
proposed fix
I'm seeing similar behavior on x86-64 with both g++-4.1.3 (ubuntu-7.10 dist)
and g++-4.2.2 build from so
--- Comment #3 from phelps at gnusto dot com 2007-12-11 10:43 ---
Added Steve Ellcey to the CC as he's the author of r115654. Hope that's not
rude.
Thanks,
-Ted
--
phelps at gnusto dot com changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-12-11 10:48 ---
I also see this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #5 from burnus at gcc dot gnu dot org 2007-12-11 10:57 ---
(In reply to comment #4)
> I also see this.
Is this with Rev. 130723 or higher? If not, can you update and try again?
If yes, can you revert libgfortran to prior 130629 and try again? That way we
know whether it is
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
The following program fails with
Error: The derived type 'func' at (1) is of type 't', which has not been
defined
module m
type t
integer :: i = 0
end type t
end module m
module mm
contains
type(t) function func()
use m
end function func
end module mm
And the now following prog
--- Comment #29 from jakub at gcc dot gnu dot org 2007-12-11 11:13 ---
Actually, I was wrong, that insn 99 is inside of the if (__count == 1) { ...
return ...; }
So it is dbr that messes this up.
Simplified testcase (only for visual inspection of the generated code, someone
with access t
--- Comment #17 from jakub at gcc dot gnu dot org 2007-12-11 11:35 ---
If fixincludes can't (at least easily) work on mingw, could we "solve" this PR
by just documenting that for GCC 4.3 the oldest supported mingw version is
3.12?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--- Comment #16 from jakub at gcc dot gnu dot org 2007-12-11 11:40 ---
But according to PR32636, gcc can bootstrap on hppa2.0w-hp-hpux11.11.
Perhaps you have a buggy linker? nm dump you posted shows definition of those
symbols...
--
jakub at gcc dot gnu dot org changed:
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-12-11 12:15
---
I guess that's sensible. We at least don't specify a version for the secondary
platform specifier i686-mingw32.
Let's downgrade this to P2 as soon as a documentation patch is provided.
(we should probably move al
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #17 from r dot emrich at de dot tecosim dot com 2007-12-11
12:26 ---
I'm completly lost. On the same machine:
Actual 4.2 branch works fine. Bootstrapping without java and using the
resulting gcc as bootstrap compiler for both configurations
hppa2.0w-hp-hpux11.00 and hppa64-h
--- Comment #17 from jakub at gcc dot gnu dot org 2007-12-11 12:35 ---
Can't reproduce any ICE on {x86_64,i686,ppc}-linux with here referenced
testcases at various flags (including e.g. -O3 -fno-strict-aliasing
-fno-tree-vectorize to make it more similar to the old setup).
The #c1 testca
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-11 12:38 ---
In reply to comment #3:
no,
int f2 = sv.f2;
does _not_ sign extend. 4.7/3 says "If the destination type is signed, the
value is unchanged if it can be represented in the destination type...".
Note your bitfield
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-12-11 12:50 ---
Reduced testcase:
extern "C" void abort() __attribute__ ((noreturn));
struct s
{
unsigned long long f1 : 40;
unsigned int f2 : 24;
} sv;
int main()
{
int f2;
sv.f2 = (1 << 24) - 1;
__asm__ volatile ("" :
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-11 12:59 ---
Actually, I'm not sure what type the shifts are supposed to be done with,
because C++ says that only bitfields smaller than int/unsigned int are
promoted.
"An rvalue for an integral bit-field (9.6) can be converted to
I believe the following code is valid and it is accepted by NAG f95, ifort and
g95. Gfortran rejects it with
Error: Invalid character in name at (1)
module m
integer, parameter :: int_t = kind(4)
end module m
integer(kind=(int_t)) function test4()
use m
test4 = 1
end function test4
F
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Statu
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-12-11 13:08 ---
Which is because
if (lang_hooks.reduce_bit_field_operations
&& TREE_CODE (type) == INTEGER_TYPE
&& GET_MODE_PRECISION (mode) > TYPE_PRECISION (type))
{
/* An operation in what may be a bit-fi
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-12-11 13:20
---
The dups also all work. Let's close this as fixed then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from zadeck at naturalbridge dot com 2007-12-11 13:30
---
Created an attachment (id=14729)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14729&action=view)
fixup of stevens hack
This hack cuts the -O compile time for the c testcase from 35 to 2 seconds.
my guess i
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-12-11 13:31 ---
Fails since 4.1.0, works up to 4.0.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from irar at il dot ibm dot com 2007-12-11 13:24 ---
The first difference I found between with and without -fno-strict-aliasing
versions of the loop in reload.c:2352 is in
with -fno-strict-aliasing (the "bad" one):
(insn 414 413 415 43 ../src/reload.c:2354 (set (reg/f:SI
--- Comment #19 from jakub at gcc dot gnu dot org 2007-12-11 13:41 ---
The testcase that was broken longest is #c3, which got fixed by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130222
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-12-11 13:34
---
I wonder what broke this. Janis, can you hunt this with the testcase in
comment #7? (g++ -O is enough)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-12-11 13:47 ---
Related to PR33887.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepend
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-12-11 13:50 ---
And 4.2.2 and 4.0.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
Hello, I am trying to port gcc-4.2.2 to the PISA architecture, for
SimplesScalar simulator. I have already created ss.h, ss.c, ss.md, ss-protos.h,
ss.opt and modified the configuration scripts accordingly. I have had it
configured just for c language, then I try to build it by typing
make all-gcc
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-11 13:54 ---
Very similar (apart from typeof) to PR30332.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-11 13:55 ---
I believe it has been fixed by
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00510.html
Please update and try again. If it still breaks, feel free to reopen the bug.
--
burnus at gcc dot gnu dot org changed:
--- Comment #18 from zadeck at naturalbridge dot com 2007-12-11 13:55
---
The thing i forgot to say in the previous post was that i had to change stevens
patch because the way that it was written causes df verify errors. You cannot
make the gen set in a block dependent on the output of
--- Comment #6 from hjl at lucon dot org 2007-12-11 13:46 ---
I saw it with revision 130726.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from hjl at lucon dot org 2007-12-11 14:03 ---
Revision 130707 is OK if I back out revision 130629.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #8 from hjl at lucon dot org 2007-12-11 14:18 ---
Revision 130726 failed after I backed out revisions 130629 and 130712.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-12-11 14:24 ---
The result needs to be truncated to a type with the bitfields precision.
"
5.8 Shift operators
... integral promotions are performed. The type of the result is that
of the promoted left operand.
...
If E1 has an
--- Comment #9 from hjl at lucon dot org 2007-12-11 14:56 ---
Revision 130726 is OK after I reverted libgfortran to revision 130629.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #2 from eesrjhc at bath dot ac dot uk 2007-12-11 15:03 ---
Thanks everyone, revision 130775 fixes the problem.
--
eesrjhc at bath dot ac dot uk changed:
What|Removed |Added
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-12-11 15:04 ---
DR315 is sort-of related, but doesn't help in this specific case (rather seems
to favor implementation defined).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33819
--- Comment #30 from jakub at gcc dot gnu dot org 2007-12-11 15:07 ---
mark_target_live_regs doesn't recognize %r28 as live on the fallthrough insn
after the branch. There are no BARRIER insns before that fallthrough insn (the
jump is conditional and there are no unconditional jumps bef
--- Comment #31 from zadeck at naturalbridge dot com 2007-12-11 15:23
---
why should r28 be live at the top of block 2? i do not know the pa at all, but
the only things that are live at the top of block 2, which can only be entered
by falling out of the entry. Things that are defined
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-12-11 15:55
---
The following fixes this failure, but breaks libjava a lot:
Index: cp/cp-lang.c
===
--- cp/cp-lang.c(revision 130773)
+++ cp/cp-lang.c
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34415
--- Comment #19 from mmitchel at gcc dot gnu dot org 2007-12-11 16:06
---
I agree. Given that the intent with MinGW is to avoid fixincludes, I guess
it's up to MinGW to provide headers that work. So, I agree that once we
document this in our release notes, we should close this bug. (
--- Comment #2 from nightstrike at gmail dot com 2007-12-11 16:10 ---
This is impeding development of the x86_64-pc-mingw32 toolchain. Is there any
way to gain help on this from the gcc community?
--
nightstrike at gmail dot com changed:
What|Removed
--- Comment #10 from pault at gcc dot gnu dot org 2007-12-11 16:17 ---
I have now developed the patch for this and PR33998 to the point where the
original testcase compiles. It is, however, missing the interface
transformation of the array_spec of 'yoagly' aka 'ugly' aka 'but_ugly'. Th
--- Comment #15 from haubi at gentoo dot org 2007-12-11 16:33 ---
Created an attachment (id=14730)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14730&action=view)
patch to avoid installing treelang info without makeinfo
This patch works with gcc-4.2.2, and should apply to trunk/g
--- Comment #10 from burnus at gcc dot gnu dot org 2007-12-11 16:37 ---
> Revision 130726 failed after I backed out revisions 130629 and 130712.
> Revision 130726 is OK after I reverted libgfortran to revision 130629.
Jerry, do you have an idea?
Between 130629 and 130726 there is my "
--- Comment #32 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-11
16:52 ---
Subject: Re: [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled
on hppa2.0w-hp-hpux11.11
> At -O2 this has:
> comib,>= 0,%r24,L$0025
> stw %r4,-72(%r30)
> comib,= 1,%
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-11 17:02 ---
cc1: internal compiler error: in common_handle_option, at opts.c:1024
Can't you debug this your self?
/* If the flag was handled in a standard way, assume the lack of
processing here is intentional.
<[EMAIL PROTECTED]> /usr/bin/gcc-4.1 -v -save-temps -m64 -D_GNU_SOURCE
-std=gnu99
-pedantic -pthread -O2 -I../gc -I../include -I../../../include -DTARGET_LINUX
-DTARGE>
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,ob
--- Comment #1 from jhr at cs dot uchicago dot edu 2007-12-11 17:05 ---
Created an attachment (id=14731)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14731&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34434
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Current trunk (130772) fails|[4.3 Regression] Current
|to build
--- Comment #4 from scovich at gmail dot com 2007-12-11 17:27 ---
(In reply to comment #3)
> Note you can declare a specialization of foo::bar which shows that the code
> is really dependent.
>
Duh! That's perfect. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34184
--- Comment #33 from pinskia at gcc dot gnu dot org 2007-12-11 17:12
---
I wonder if http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00506.html also fixes
this code too which mentions dbr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
Using snapshot: gcc-4.3-20071109
Problem code follows:
///
#include
class Vec {
__m128i vec;
public:
Vec(int mm) {
vec = _mm_set1_epi16(mm);
}
operator __m128i() const {
return vec;
}
};
int main() {
_mm_shuffle_epi32(Vec(5), _MM_SHUFFLE(3,3,3,3)); /
--- Comment #4 from asteinarson at gmail dot com 2007-12-11 17:55 ---
(In reply to comment #2)
> Created an attachment (id=14728)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14728&action=view) [edit]
> proposed fix
>
> I'm seeing similar behavior on x86-64 with both g++-4.1.3 (u
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-12-11 18:58
---
I cannot reproduce this on native i686 either with
g++-4.2 --version
g++-4.2 (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the sour
--- Comment #11 from aldyh at gcc dot gnu dot org 2007-12-11 19:04 ---
testing a patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-12-11 19:15 ---
Hey Wolfgang, I cannot reproduce this:
g++ -g -O2 -march=native -fopenmp -D_GLIBCXX_PARALLEL 34059.cc
Seems to run fine for me. I'm using
g++ (GCC) 4.3.0 20071209 (experimental)
-benjamin
--
http://gcc.gnu.o
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-12-11 19:17 ---
It also works for me with:
GNU C++ (GCC) version 4.3.0 20071205 (experimental) [trunk revision 130629]
(spu-elf)
Are you sure you don't have a modified compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #13 from jkrahn at nc dot rr dot com 2007-12-11 19:40 ---
My previous post here was a bit confused by differences in F95 and F2003, and
my misunderstanding of Gfortran's BOZ extension.
As I understand the F2003 standard, the expression "INT(z'ff',1)" should
produce a range e
--- Comment #11 from hjl at lucon dot org 2007-12-11 20:16 ---
[EMAIL PROTECTED] 34427]$ cat foo.f90
IMPLICIT NONE
real , DIMENSION(11) ::foo
integer :: isfflx
NAMELIST /nl/ foo
NAMELIST /nl/ isfflx
open (10, status="scratch")
write (10,*) " &nl"
write (10,*) " foo = 5,
--- Comment #19 from ludovic at ludovic-brenta dot org 2007-12-11 20:36
---
With the patch from comment #17, the compile time is down to
real130m10.559s
user130m9.104s
sys 0m0.388s
on my machine. You seem to be on the right track :)
--
http://gcc.gnu.org/bugzilla/show
--- Comment #12 from hjl at lucon dot org 2007-12-11 20:58 ---
Revision 130708 is wrong. We can't do
if ((c == 'i' || c == 'I')
&& ((c = next_char (dtp)) == 'n' || c == 'N')
&& ((c = next_char (dtp)) == 'f' || c == 'F'))
{
...
if (nml_bad_return (dtp, c))
return
--- Comment #34 from jakub at gcc dot gnu dot org 2007-12-11 20:37 ---
Answers (note, I don't know PA at all either):
1) in a function that returns struct, %r28 is what
targetm.calls.struct_value_rtx gives:
/* Register in which address to store a structure value
is passed to a func
--- Comment #2 from bangerth at dealii dot org 2007-12-11 20:55 ---
(In reply to comment #1)
> Hey Wolfgang, I cannot reproduce this:
>
> g++ -g -O2 -march=native -fopenmp -D_GLIBCXX_PARALLEL 34059.cc
>
> Seems to run fine for me. I'm using
>
>
> g++ (GCC) 4.3.0 20071209 (experiment
--- Comment #35 from jakub at gcc dot gnu dot org 2007-12-11 21:28 ---
df_get_entry_block_def_set has this:
/* Once the prologue has been generated, all of these registers
should just show up in the first regular block. */
if (HAVE_prologue && epilogue_completed)
{
/*
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconf
--- Comment #13 from hjl at lucon dot org 2007-12-11 21:06 ---
Also are inf/infinity/infbar/infinityfoo/nan/nanfoo valid variables?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #36 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-11
21:44 ---
Subject: Re: [4.3 Regression] 25_algorithms/search_n/iterator.cc: miscompiled
on hppa2.0w-hp-hpux11.11
> 2) the instruction to load lo_sum of the address has not been dropped, I
> posted
>only part o
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-12-11 21:48 ---
Subject: Bug 34015
Author: bkoz
Date: Tue Dec 11 21:48:16 2007
New Revision: 130778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130778
Log:
2007-12-11 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-12-11 22:21 ---
HJ: this and 33831 are the same thing. I would appreciate it if you could
either clarify why you think they are separate, or close one of them. I suggest
closing 33832.
This PR I will treat as "How HJ can fix eon in S
--- Comment #5 from phelps at gnusto dot com 2007-12-11 22:30 ---
Created an attachment (id=14732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14732&action=view)
minimal test case
This attachment contains a minimal C++ program that exhibits the behavior. The
program should exit
Appears to be invalid code produced when -mthumb selected.
Happens with gcc 4.1.1 and 4.2.2 when compiling with:
arm-rtems4.9-gcc -mcpu=arm7tdmi -mthumb -O2 -c /tmp/test1.c
/tmp/cccISkv7.s: Assembler messages:
/tmp/cccISkv7.s:205: Error: unshifted register required -- `eor
r2,r3,r3,ROR#16'
--- Comment #14 from hjl at lucon dot org 2007-12-11 22:31 ---
The current Inf/NAN I/O support is broken. Given a namelist input
&nl
foo = 5,
infinity1 = 1,
/
where foo is an array of 2 reals, we need to unget up to 8 chars (infinity).
If it can't be done with the current runtime
--- Comment #1 from joel at gcc dot gnu dot org 2007-12-11 22:32 ---
Created an attachment (id=14733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14733&action=view)
Test Case #1 produces illegal assembly
When compiled as described in the first post, this file gives illegal assem
--- Comment #2 from joel at gcc dot gnu dot org 2007-12-11 22:34 ---
Found inline assembly that caused problem. Sorry.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
The following test failures on powerpc64-linux with -m32:
FAIL: gcc.dg/vect/no-scevccp-outer-10a.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10b.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-11.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-12.c execution test
--- Comment #15 from hjl at lucon dot org 2007-12-11 22:37 ---
We can change the last_char field to
#define MAX_LAST_STRING_LEN 8
char last_string[MAX_LAST_STRING_LEN];
int last_char_pos;
we can unget up to MAX_LAST_STRING_LEN chars.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #4 from joel dot sherrill at oarcorp dot com 2007-12-11 22:38
---
Subject: Re: Illegal assembly on ARM/Thumb
pinskia at gcc dot gnu dot org wrote:
> --- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-11 22:35
> ---
> asm volatile ("EOR %1, %0, %0, R
--- Comment #16 from burnus at gcc dot gnu dot org 2007-12-11 22:47 ---
> Also are inf/infinity/infbar/infinityfoo/nan/nanfoo valid variables?
I think they are. But none which start with an integer or a '+'/'-'/'.', which
is why the old technique "Read a single character, if it is not v
1 - 100 of 137 matches
Mail list logo
