--- Comment #23 from burnus at gcc dot gnu dot org 2007-12-12 07:20 ---
> Tobias. do as you
> please. We can either revert the original patch and get back to this without
> time pressure or proceed quickly.
Maybe reverting and proceeding then quickly w/o time pressure is best.
> With t
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Statu
--- Comment #1 from komila dot srivastava at infogain dot com 2007-12-12
06:23 ---
Created an attachment (id=14737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14737&action=view)
Contact Search Apge
Bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34441
PDM Event Functionality
--
Summary: PDM
Product: gcc
Version: 2.95
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: komila dot sriva
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-12-12 04:34
---
Reply to comment #20:
It does not matter since we translate all variable names to lower case. It
would matter if we used this mechanism to read literal string constants, but we
don't. I will look that over a b
--- Comment #4 from victork at gcc dot gnu dot org 2007-12-12 04:06 ---
I have tried both testcases with compiler built from svn branch of 4.2
(svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch) on x86_64.
Both cases run correctly. Looks like this bug is already fixed in 4.2 and 4.3.
--- Comment #21 from hjl at lucon dot org 2007-12-12 01:56 ---
(In reply to comment #18)
> Created an attachment (id=14736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14736&action=view) [edit]
> Draft Patch
>
> Test patch. It seems to fix the REAL reading part. I run out of tim
--- Comment #3 from danglin at gcc dot gnu dot org 2007-12-12 01:44 ---
Sorry, this is an unresolved issue with the hppa-linux test infrastructure.
Tests that produce a lot of output sometimes have their output truncated.
Whether a test fails or not is sometimes timing related. This wou
--- Comment #20 from jakub at gcc dot gnu dot org 2007-12-12 01:14 ---
When you mention that, is it right that you are pushing different chars than
what has been actually read? E.g.:
c = tolower (next_char (dtp));
l_push_char (dtp, c);
Shouldn't that be instead:
c = next_char (dtp
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2007-12-12 01:05
---
We have a mechanism already in list_read.c to allow transparently reading ahead
and buffering as far as we need to. I wish I had been able to respond to this
report sooner and could have saved some time.
Its ca
--- Comment #15 from jkrahn at nc dot rr dot com 2007-12-12 01:04 ---
Subject: Re: Warn with -std=f95/f2003 when BOZ is used
at invalid places
burnus at gcc dot gnu dot org wrote:
...
>> Maybe there should be a "-f[no-]boz-range-check" to exclude range errors just
>> for the BOZ case.
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-12 00:31 ---
See also bug 18560. I.e. consider using a C version instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
--- Comment #18 from burnus at gcc dot gnu dot org 2007-12-12 00:03 ---
Created an attachment (id=14736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14736&action=view)
Draft Patch
Test patch. It seems to fix the REAL reading part. I run out of time for the
COMPLEX part (parse_re
--- Comment #12 from janis at gcc dot gnu dot org 2007-12-11 23:56 ---
Before noticing comment #9, I tested a few saved installs of trunk and ran a
regression hunt for trunk on powerpc-linux using the testcase from comment #7,
which found this patch that caused the test to start failing:
--- Comment #1 from oliver dot kellogg at eads dot com 2007-12-11 23:42
---
Created an attachment (id=14735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14735&action=view)
source code for producing the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34440
$ gcc -c -v p_mvc-dpmodel.adb
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../SOURCES/gcc/configure --prefix=/opt/gccsnap
--enable-debug --enable-languages=c,ada,c++
Thread model: posix
gcc version 4.3.0 20071211 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c'
--- Comment #17 from kargl at gcc dot gnu dot org 2007-12-11 23:31 ---
(In reply to comment #16)
> > 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
--- Comment #4 from janis at gcc dot gnu dot org 2007-12-11 23:27 ---
The patch in comment #3 works, except that there need to be quotes around each
option: "-maltivec" "-mabi=altivec".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34437
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-12-11 23:25 ---
HJ:
"I don't know if gcc 4.3 provides the identical functionality as the old one."
We've all answered this multiple times by now. Quick answer: yes.
See #5.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #1 from kargl at gcc dot gnu dot org 2007-12-11 23:22 ---
Can you provide a standard conforming program that
illustrates the problem (because your code violates
the standard)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
--- Comment #3 from joel at gcc dot gnu dot org 2007-12-11 23:22 ---
And again on 4.1.1:
$ /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -m528x -c j.c
j.c: In function '_shttpd_elog':
j.c:7557: error: insn does not satisfy its constraints:
(insn 14 190 15 (set (mem/c:SI (plus:SI (reg/f:SI 14 %a
--- Comment #2 from joel at gcc dot gnu dot org 2007-12-11 23:22 ---
Also occurs on 4.2.1 but this time at:
/opt/rtems-4.8/bin/m68k-rtems4.8-gcc -m528x -c j.c
j.c: In function '_shttpd_elog':
j.c:7557: error: insn does not satisfy its constraints:
(insn 13 189 14 (set (mem/c:SI (plus:S
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-12-11 23:21 ---
Changed the tile to something unique.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from joel at gcc dot gnu dot org 2007-12-11 23:20 ---
Created an attachment (id=14734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14734&action=view)
Preprocessed code that produces error
This is the preprocessed output of the Simple HTTPD server for RTEMS compile
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-12-11 23:20 ---
Re: #7.
Sorry about the timing. I agree it is unfortunate.
I do believe that the correct timing on this is to do both new C++0x interfaces
and the revised backwards includes at the same time. (Certainly, this fits i
--- Comment #1 from daney at gcc dot gnu dot org 2007-12-11 23:20 ---
Verified that it works on MontaVista build 3.4.3.
Still failing on:
armv5tl-montavista-linuxeabi-g++ (GCC) 4.3.0 20071211 (experimental) [trunk
revision 130777]
--
daney at gcc dot gnu dot org changed
m68k-rtems4.9-gcc -m528x -c j.c
gcc 4.2.2
../../../../../../current/c/src/../../cpukit/shttpd/log.c:139: error: insn does
not satisfy its constraints:
(insn 74 158 159 10
../../../../../../current/c/src/../../cpukit/shttpd/log.c:117 (set (mem/c:SI
(plus:SI (reg/f:SI 14 %a6)
(reg
--- Comment #14 from burnus at gcc dot gnu dot org 2007-12-11 23:15 ---
> As I understand the F2003 standard, the expression "INT(z'ff',1)" should
> produce a range error, for the same reasons as the data statement illustrated
> in:
> http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-co
ared
--enable-languages=c,c++,fortran --enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.3 20071211 (prerelease)
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.x/configure --enable-shared
--enable-languages=c,c++,fortran --enable-th
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-11 23:08 ---
Or someone messed up vect.exp :(.
Anyways try this patch:
Index: testsuite/gcc.dg/vect/vect.exp
===
--- testsuite/gcc.dg/vect/vect.exp (revision 1
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-11 23:05 ---
No the autovectorizer testsuite uses -mabi=altivec also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34437
--- Comment #1 from jakub at gcc dot gnu dot org 2007-12-11 23:00 ---
See http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00340.html
Apparently -m32 -maltivec has been always badly broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34437
--- Comment #7 from hjl at lucon dot org 2007-12-11 23:00 ---
This one is for "moved" header files. One can include different header files
for gcc 4.3. PR 33831 is for "removed" header files. I don't know if gcc
4.3 provides the identical functionality as the old one. One may needs more
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-12-11 22:57 ---
Really the change happened too late in the release cycle which is why people
are complaining about this change and it is not that advertised that it would
break many people's code. In my mind, we should wait for 4.4
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-12-11 22:56 ---
The gcc-4.3 release intentionally changes the libstdc++ API. It is intended
with this release that either:
C++98
or
C++0x
will be used, and that either dialect will work with both TR1 and the various
extensions lis
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-11 22:49 ---
Benjamin, the patch in #c4 looks good to me and this is a very severe bug,
could
you please review the patch and apply if you agree?
Wonder what kind of testing was done before r115654 commit :(.
--
jakub at gcc do
--- 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
--- 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 #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=
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 #3 from pinskia at gcc dot gnu dot org 2007-12-11 22:35 ---
asm volatile ("EOR %1, %0, %0, ROR #16\n"
"BIC %1, %1, #0xff\n"
"MOV %0, %0, ROR #8\n"
"EOR %0, %0, %1, LSR #8\n"
: "=r" (value)
--- 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
--- 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 #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
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 #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
--- 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 #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 #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
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconf
--- 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)
{
/*
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Current trunk (130772) fails|[4.3 Regression] Current
|to build
--- 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
<[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 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.
--- 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 #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 #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 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 #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 #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. (
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 137 matches
Mail list logo
