I was recompiling the linux kernel on a mips ip32 system (an SGI O2) whith only
on change in config. I changed CONFIG_BUILD_ELF64 to 'n'.
Then, while rebuilding with
sgi:~# gcc -v
Using built-in specs.
Target: mips-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,obj
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-31 06:21 ---
(Close the bug myself.)
The ICE mentioned in the subject is FIXED for the trunk.
As said, PR 33254 tracks the run-time diagnostic for different string lengths
in array constructors.
--
burnus at gcc dot gnu dot
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-31 06:10 ---
(In reply to comment #4)
> does not generate the runtime error that it should, so I am leaving this PR
> open. I have unassigned myself for now but might well return to this soon.
I think it should be enough to give
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-31 06:08 ---
See also PR 32703; example found by Paul and compared with other compilers by
Dominique and me.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from kargl at gcc dot gnu dot org 2007-08-31 05:29 ---
(In reply to comment #10)
> Now to the more confusing issue of backporting. I managed to find the
> following:
>
(Stuff from Mark removed)
You're quoting email out of context.
>
> Mr Kargl explains what happened f
--- Comment #14 from raeburn at raeburn dot org 2007-08-31 04:42 ---
Subject: Re: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
On Aug 30, 2007, at 3:55, andreagrassi at sogeasoft dot com wrote:
> A last thing if
--- Comment #10 from michelin60 at gmail dot com 2007-08-31 04:33 ---
(In reply to comment #7)
> Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase
>
> > Second I mentioned Mark Mitchell because he, as relesae manager, put a stop
> > to backporting definitely aggravating produc
--- Comment #3 from sandra at gcc dot gnu dot org 2007-08-31 03:25 ---
Subject: Bug 33211
Author: sandra
Date: Fri Aug 31 03:25:02 2007
New Revision: 127951
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127951
Log:
2007-08-30 Sandra Loosemore <[EMAIL PROTECTED]>
PR m
--- Comment #9 from kargl at gcc dot gnu dot org 2007-08-31 02:43 ---
> Second I mentioned Mark Mitchell because he, as relesae manager, put a stop
> to backporting definitely aggravating productive use of GCC.
I'm disinterested in the rest of this PR, but I will comment on the above.
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-08-31 02:39
---
As Andrew stated, most of these testsuite failures were due to a regression
caused by one of my patches. I do monitor bugzilla submissions during the day.
However, I do this work in the evenings as a volunteer.
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-31
01:53 ---
Subject: Re: [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global
destructors keyed to _ZNSt3tr112_GLOBAL__N_16i
> Was this fixed?
No, there are still duplicate symbol failures as reported in commen
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-31 01:51 ---
Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase
On 31 Aug 2007 01:43:51 -, michelin60 at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Second I mentioned Mark Mitchell because he, as relesae manager, put
On 31 Aug 2007 01:43:51 -, michelin60 at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Second I mentioned Mark Mitchell because he, as relesae manager, put a stop to
> backporting
> definitely aggravating productive use of GCC.
This is the trunk we are talking about, I am seriously thinking you
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-31 01:47 ---
Most likely what is happening is that DECL_UIDs are different so they will
produce different code because of that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-31 01:45 ---
Related to PR 9552.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-08-31 01:44
---
'*' is not valid so closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from michelin60 at gmail dot com 2007-08-31 01:43 ---
(In reply to comment #5)
> First off don't CC anyone unless there is a real reason to like you know they
> caused the issue. Second most of the rest of the failures are PR 33225
> anyways.
>
First of all I CC'd Dr. Ed
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-08-31 01:43
---
Patch causing regression reverted. Closing this PR. Thanks for reporting.
The next round on the per kind write float patch will have these test cases
addressed.
--
jvdelisle at gcc dot gnu dot org changed
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-31 01:41 ---
Was this fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-08-31 01:37
---
Subject: Bug 33225
Author: jvdelisle
Date: Fri Aug 31 01:37:31 2007
New Revision: 127950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127950
Log:
2007-08-30 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-31 01:36 ---
(gdb) p/x sect->common.flags & ~0x10
$4 = 0x20
(gdb) p/x flags
$5 = 0x200200
Note 0x10 is SECTION_DECLARED which is masked out in the check.
#define SECTION_WRITE0x00200/* data is writable
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-31 01:15 ---
First off don't CC anyone unless there is a real reason to like you know they
caused the issue. Second most of the rest of the failures are PR 33225
anyways.
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-31 01:10 ---
Fixed, already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #9 from gdr at cs dot tamu dot edu 2007-08-31 01:03 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 31 Aug 2007, fang at csl dot cornell dot edu wrote:
| Aren't unused typedefs sometimes useful for static assertions and concept
| checking, using templates?
Maybe
--- Comment #4 from michelin60 at gmail dot com 2007-08-31 00:47 ---
(> Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase
>
> > /var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
> > ERROR: could not compile testsuite_abi.cc
>
> This was fixed by:
> 2007-08-30
--- Comment #8 from fang at csl dot cornell dot edu 2007-08-31 00:33
---
Aren't unused typedefs sometimes useful for static assertions and concept
checking, using templates? I suppose if one really wanted to keep around an
unused typedef, that __attribute__((unused)) might be somehow a
--- Comment #7 from gdr at cs dot tamu dot edu 2007-08-31 00:05 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 30 Aug 2007, pcarlini at suse dot de wrote:
| Well, assuming there are no "no-go" theorems about that problem ;) I would be
| certainly interested in studying the
--- Comment #6 from pcarlini at suse dot de 2007-08-30 23:59 ---
Well, assuming there are no "no-go" theorems about that problem ;) I would be
certainly interested in studying the problem in better detail...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
--- Comment #5 from gdr at cs dot tamu dot edu 2007-08-30 23:51 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 30 Aug 2007, pcarlini at suse dot de wrote:
|
|
| --- Comment #4 from pcarlini at suse dot de 2007-08-30 23:46 ---
| (In reply to comment #3)
| > Maybe
--- Comment #4 from pcarlini at suse dot de 2007-08-30 23:46 ---
(In reply to comment #3)
> Maybe the original idea could be refined to *local* typedef
> declarations.
Of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-30 23:43 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 30 Aug 2007, pinskia at gcc dot gnu dot org wrote:
| I think it is wrong to warn for unused typedefs, they are all over headers.
In general, I tend to agree with
--- Comment #2 from pcarlini at suse dot de 2007-08-30 23:33 ---
Careful, only *in function bodies*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-30 23:30 ---
I think it is wrong to warn for unused typedefs, they are all over headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
Just a wild idea, motivated by libstdc++/33084: in that case we had a function
with this body:
typedef _BinClos<_Name, _Constant, _ValArray, _Tp, _Tp> _Closure;
typedef typename __fun<_Name, _Tp>::result_type _Rt;
return _Expr<_Closure, _Tp>(_Closure(__t, __v));
where the fact t
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-08-30
23:15 ---
thanks!
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2007-08-30 22:24 ---
Subject: Re: TAB in FORMAT: accept extension, warn with -std=f*
On Thu, Aug 30, 2007 at 09:52:56PM -, fago at caltech dot edu wrote:
>
> --- Comment #12 from fago at caltech dot edu 200
--- Comment #4 from pault at gcc dot gnu dot org 2007-08-30 22:18 ---
This no longer segfaults and it generates correct code for valid fortran.
However,
program array_char
implicit none
character (len=2) :: x, y
x = "a "
y = "cd"
print*,[trim(x),trim(y)]
end program array_char
does no
--- Comment #8 from pault at gcc dot gnu dot org 2007-08-30 22:13 ---
Fixed on trunk.
Thanks for the report!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #23 from pault at gcc dot gnu dot org 2007-08-30 22:13 ---
Fixed on trunk.
Thanks for the report!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pault at gcc dot gnu dot org 2007-08-30 22:12 ---
Fixed on trunk.
Thanks for the report!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pault at gcc dot gnu dot org 2007-08-30 22:11 ---
Subject: Bug 31879
Author: pault
Date: Thu Aug 30 22:10:55 2007
New Revision: 127939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939
Log:
2007-08-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #22 from pault at gcc dot gnu dot org 2007-08-30 22:11 ---
Subject: Bug 31197
Author: pault
Date: Thu Aug 30 22:10:55 2007
New Revision: 127939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939
Log:
2007-08-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #7 from pault at gcc dot gnu dot org 2007-08-30 22:11 ---
Subject: Bug 31258
Author: pault
Date: Thu Aug 30 22:10:55 2007
New Revision: 127939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939
Log:
2007-08-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2007-08-30 22:11 ---
Subject: Bug 32703
Author: pault
Date: Thu Aug 30 22:10:55 2007
New Revision: 127939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127939
Log:
2007-08-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #12 from fago at caltech dot edu 2007-08-30 21:52 ---
A stupid question: why cannot gfortran detect this invalid code at compile
time? I was quite surprised by a runtime error.
BTW, I was compiling some legacy code with 4.2.1 and just hit this ...
--
http://gcc.gnu.org/
The following program is invalid Fortran 95/2003, but this cannot be diagnosed
at compile time:
program array_char
implicit none
character (len=2) :: x, y
x = "a "
y = "cd"
print*,[trim(x),trim(y)] ! [ "a", "cd" ] ->INVALID: different string lengths
end program array_char
While behavior of gfortr
--- Comment #11 from zadeck at naturalbridge dot com 2007-08-30 21:46
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
rakdver at gcc dot gnu dot org wrote:
> --- Comment #10 from rakdver at gcc dot gnu dot org 2007-08-30 20:05
> ---
> I know how to fix the proble
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33205
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-30 21:19 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Target Milestone|--- |4.2.2
ht
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-30 21:15 ---
I have a patch which needs testing for the trunk.
I am thinking about adding to my normal testing -mminimal-toc with -m64.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-30 21:09 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-30 21:09 ---
Not a GCC bug so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-30 21:06 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-30 21:04 ---
The following code:
real x
x = 1.0
print '(3E20.2e2)', x, x/10.0, x/100.0
print '(3E20.2e3)', x, x/10.0, x/100.0
print '(3E20.2e4)', x, x/10.0, x/100.0
print '(3E20.2e5)', x, x/10.0, x/100.0
print '(3E20.2e6)', x, x/
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-30 20:15 ---
Should be fixed now, see
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127928
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-08-30 20:05
---
I know how to fix the problem, now.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from patchapp at dberlin dot org 2007-08-30 19:45 ---
Subject: Bug number PR 30315
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from William dot H dot Daffer at jpl dot nasa dot gov
2007-08-30 19:33 ---
Subject: Re: f77 reads one field into two variables in
list directed i/o
On Thu, 2007-08-30 at 18:26 +, burnus at gcc dot gnu dot org wrote:
>
> --- Comment #1 from burnus at gcc
--- Comment #9 from zadeck at naturalbridge dot com 2007-08-30 18:57
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
zadeck at naturalbridge dot com wrote:
> --- Comment #8 from zadeck at naturalbridge dot com 2007-08-30 18:51
> ---
> Subject: Re: failing rtl iv
Reading back a namelist string which contains an
apostrophe doesn't work.
I am marking this as an enhancement because reading back
what we wrote with a namelist isn't guaranteed to work
(see note 10.37 in the working draft). It does work with
ifort, for example.
$ cat namelist.f90
program main
--- Comment #5 from claumann at princeton dot edu 2007-08-30 18:51 ---
Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel
mac
Great! Will do. Sorry to take your time.
Chris
On Aug 30, 2007, at 12:44 PM, pinskia at gmail dot com wrote:
>
>
> --- Comment #4
--- Comment #8 from zadeck at naturalbridge dot com 2007-08-30 18:51
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
rakdver at kam dot mff dot cuni dot cz wrote:
> --- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30
> 18:09 ---
> Subject: Re:
--- Comment #4 from pinskia at gmail dot com 2007-08-30 18:44 ---
Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel
mac
On 30 Aug 2007 18:40:51 -, claumann at princeton dot edu
<[EMAIL PROTECTED]> wrote:
> build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a
On 30 Aug 2007 18:40:51 -, claumann at princeton dot edu
<[EMAIL PROTECTED]> wrote:
> build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a=0x0,
> ddr_b=0x434af898, dist_v=0x7b4d8c, init_b=0x434e9bd0 "A",
> index_carry=0x7) at ../../gcc-4.3-20070810/gcc/tree-data-ref.c:2719
> 2719../../gcc-4.3
--- Comment #3 from claumann at princeton dot edu 2007-08-30 18:40 ---
Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel
mac
Howdy-
Thanks for looking into it!
It compiles just fine with
gfortran -c dqelg.f
I'm not especially excited about trying to compil
--- Comment #3 from pinskia at gmail dot com 2007-08-30 18:35 ---
Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase
> /var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
> ERROR: could not compile testsuite_abi.cc
This was fixed by:
2007-08-30 Jakub Jelinek <
> /var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
> ERROR: could not compile testsuite_abi.cc
This was fixed by:
2007-08-30 Jakub Jelinek <[EMAIL PROTECTED]>
PR target/33168
* config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Return
true if any of
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 18:26 ---
I tried you example with g77 and it shows "No Error". However, using all other
compilers I have (ifort, sunf95, openf95, g95, gfortran, NAG f95) it shows
"Error!".
...
Ok, after re-reading your bug report, I see tha
43/gcc-4.3.0/gcc/testsuite/g++.dg/compat/compat.exp ...
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/compat/struct-layout-1.exp
> ...
> WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
> Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/g++.dg/debug/debug.exp ...
> R
PASS: g++.dg/tree-ssa/copyprop-1.C scan-tree-dump-not .* = [^>;]*;
FAIL: g++.dg/warn/Wall-write-strings.C (test for warnings, line 5)
FAIL: g++.dg/warn/write-strings-default.C (test for warnings, line 6)
FAIL: g++.dg/warn/write-strings.C (test for warnings, line 6)
Running /var/tmp/43/gcc-4.
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-30 18:12 ---
(gfortran bugs are by definition not critical or major for GCC as a whole;
still the gfortran team tries to fix regressions as soon as possible.)
I cannot reproduce this problem with today's gfortran on
x86_64-unknow
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
l-float --disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070830 (experimental) (GCC)
The significant increase concerns gfortran; but, others appear high.
This
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30
18:09 ---
Subject: Re: failing rtl iv analysis (maybe due to df)
> The only thing that you are allowed to do with the DF_REF_ID is to get
> it from a df_def
> AFTER YOU ARE SURE THAT THE DEF IS IN THE REGION
OK, th
--- Comment #12 from daney at gcc dot gnu dot org 2007-08-30 17:44 ---
Does GCJ's behavior differ from Sun's in this test?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
--- Comment #1 from claumann at princeton dot edu 2007-08-30 17:25 ---
Compiles with no errors using gfortran 4.2.1 for i686-apple-darwin8.
--
claumann at princeton dot edu changed:
What|Removed |Added
--
The problem is that the I/O system reads one (admittedly malformed)
field into two variables in list directed input.
Take this one line and put it in a file named 'the_test_file'
- cut - cut - cut - cut
13.5-1420.83 10.350E+00 -0.181E+19
- cut --
--- Comment #4 from victor dot prosolin at gmail dot com 2007-08-30 17:09
---
I am sorry for posting such a long example, but the code was not written by me
so I didn't want to make stupid changes. It's my first time reporting a bug via
bugzilla so don't be too critical about me not fig
During gfortran compilation of the integration subpack of scipy-0.5.2.1,
gfortran fails with an "internal compiler error: Bus error" when trying to
compile dqelg.f.
Command line and error info:
gfortran:f77: Lib/integrate/quadpack/dqelg.f
Lib/integrate/quadpack/dqelg.f: In function 'dqelg':
Lib/i
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-30 16:43 ---
Subject: Bug 33168
Author: jakub
Date: Thu Aug 30 16:43:19 2007
New Revision: 127928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127928
Log:
PR target/33168
* config/rs6000/rs6000.c (rs6000_
--- Comment #9 from jason at gcc dot gnu dot org 2007-08-30 16:33 ---
Fixed by Simon Martin.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from jason at gcc dot gnu dot org 2007-08-30 16:30 ---
Fixed for 4.3, IMO not enough evident interest in the bug to bother
backporting.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-30 16:29 ---
> dorit,
> i am having trouble exactly reproducing this example because you did not
> give the svn revision and so all of the numbers are a little bit
> different.
it's revision 127623
> However, I am going to submi
--- Comment #80 from schwab at suse dot de 2007-08-30 16:10 ---
*** Bug 33248 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
--- Comment #3 from schwab at suse dot de 2007-08-30 16:10 ---
It invokes undefined behaviour, if it breaks you get to keep the pieces. There
is no requirement that you get any useful result.
http://c-faq.com/expr/evalorder1.html
*** This bug has been marked as a duplicate of 11751 **
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-08-30 15:24 ---
Subject: Re: New: Missed opportunities for vectorization due to PRE
On 30 Aug 2007 02:55:17 -, spop at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The following loop showing up in the top time users in cap
--- Comment #2 from alduc1 at free dot fr 2007-08-30 15:22 ---
I do not think it is the same bug 11751.
For example:
*p++ = *p + 1.0;
*p++ = *p + 1.0;
works. But
*p++ = (float) floor((double) *p + 0.5);
*p++ = (float) floor((double) *p + 0.5);
does not work (with float). It
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-30 15:03 ---
Can reproduce the problems with x86-64/Linux. -m64 works, but -m32 fails.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-08-30 14:56
---
(In reply to comment #23)
> I don't think the patch fixes anything.
Uh, sure it does.
Before we were ignoring the pointer results from calls.
They should point to anything.
> Can you elaborate on
>
> "D.8892
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-08-30 14:52
---
Subject: Bug 33199
Author: rguenth
Date: Thu Aug 30 14:52:28 2007
New Revision: 127927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127927
Log:
2007-08-30 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-30 14:43 ---
This works for me on x86_64 and i686. Possibly a rtl-optimization or target
bug.
As there were loop fixes after 4.1.2 went out can you try with the trunk of
the gcc-4_1-branch or give the exact version of your compi
--- Comment #4 from zadeck at naturalbridge dot com 2007-08-30 14:43
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
dorit at gcc dot gnu dot org wrote:
> --- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 ---
> (In reply to comment #2)
>
>> I su
The following code gives different results with -O3 (or -O2) and no
optimization.The -O3 output is wrong.
try:
$g++ -O3 test.cpp
$cat test.cpp
#include
class foo
{
int _type;
public:
foo( int t ) : _type(t) {};
bool is_1() { return _type == 1; }
bool is_23() { return _type == 2 ||
--- Comment #3 from spop at gcc dot gnu dot org 2007-08-30 14:19 ---
Subject: Re: Missed opportunities for vectorization due to unhandled real_type
Thanks for the detailed comments and further investigation.
On 30 Aug 2007 10:12:26 -, dorit at gcc dot gnu dot org >
> I couldn't co
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-30 13:47 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
1 - 100 of 129 matches
Mail list logo
