--- Comment #7 from tehila at il dot ibm dot com 2007-01-07 08:03 ---
Right, the vectorizer currently supports conversions only between integral
types. Support for type conversions that involve also floating-point types are
in the works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-01-07 09:09
---
I cannot confirm at the moment, I stopped testing 4.0.x on SPARC in March!
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
Lots of bounds-checking errors in this program...
$ cat string_check.f90
program main
character (len=4) :: a,b
character (len=1) :: c
a = 'aa '
b = trim(a) ! RHS is too short
a = repeat('b', 2) ! RHS is too short
c = trim(a) ! LHS is too short, string out of bounds
c = r
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-07 11:04 ---
Actualy, there aren't, I was confused.
Sorry :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dcb314 at hotmail dot com 2007-01-07 12:08 ---
(In reply to comment #2)
> I think this was fixed by:
> 2007-01-02 Joseph Myers <[EMAIL PROTECTED]>
> Can you check to make sure?
Seems fixed to me.
--
dcb314 at hotmail dot com changed:
What|Remo
--- Comment #18 from patchapp at dberlin dot org 2007-01-07 12:55 ---
Subject: Bug number PR7651
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-01/msg00503.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from rask at sygehus dot dk 2007-01-07 14:07 ---
I tried to build several versions to find out which ones work:
GCC 4.0.3 works (dies later compiling newlib/libc/math/e_j0.c).
GCC 4.1.0 unknown (fails to compile rs6000.c).
GCC 4.1.1 works (dies later with bug 27075).
GCC
--- Comment #8 from rask at sygehus dot dk 2007-01-07 14:16 ---
Created an attachment (id=12869)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12869&action=view)
updated patch in testing
Here's a new patch as discussed. The GCC 4.2 branch now manages to build
libgcc2. I haven't tr
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-07
15:51 ---
Subject: Re: [hppa64-hp-hpux11.11] libstdc++-v3 fails to build with HP
assembler
> --- Comment #6 from jbuck at gcc dot gnu dot org 2007-01-07 07:30 ---
> Should this one just be marked WONTFIX?
--- Comment #13 from aldot at gcc dot gnu dot org 2007-01-07 16:23 ---
Subject: Bug 27698
Author: aldot
Date: Sun Jan 7 16:23:45 2007
New Revision: 120549
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120549
Log:
fortran/ChangeLog
2007-01-03 Bernhard Fischer <[EMAIL PROTECT
/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu/gcc/gcc
-4.3.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11
/lib/ -isystem /opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/include -isystem
/op
t/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/sys-include -D
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-01-07 17:04 ---
Patch committed by Bruce Korb, bootstrapped and regtested.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-07 17:44
---
In extract_range_from_binary we have another case where we drop to varying:
/* For integer ranges, apply the operation to each end of the
range and see what we end up with. */
if (code == TRUTH_ANDIF_EXP
--- Comment #11 from tobi at gcc dot gnu dot org 2007-01-07 19:42 ---
We should maybe install the workaround if the optimizer bug doesn't get fixed
soon, as a Fortran FE that produces wrong code for most Fortran 90 codes is
probably not something we want.
--
http://gcc.gnu.org/bugzi
--- Comment #8 from dorit at il dot ibm dot com 2007-01-07 20:22 ---
I'm testing this patch, that makes us more conservative, and concludes that two
pointers don't overlap only if both are "based on" restricted pointers, with
"based on" trivially implemented as the pointer used in the re
--- Comment #19 from patchapp at dberlin dot org 2007-01-07 21:05 ---
Subject: Bug number PR7651
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-01/msg00520.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-07 21:15 ---
Kaveh,
As the culprit for both patches, I'll take a look. I had no idea that there
was and 4.1 regressions associated with them. I'll come back to you.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-07 22:33 ---
This would definitely be useful.
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-07 23:40 ---
Subject: Bug 28986
Author: manu
Date: Sun Jan 7 23:39:55 2007
New Revision: 120558
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120558
Log:
2007-01-07 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c+
--- Comment #9 from drow at gcc dot gnu dot org 2007-01-07 23:42 ---
For mainline, I would suggest using configure to check whether
-mlong-double-128 can be used, for targets where it would be used by the
makefile fragments. That will handle multilibs properly, et cetera. Unless
after
--- Comment #1 from pcarlini at suse dot de 2007-01-08 00:30 ---
Dave, can you have a look to this PR? AFAIK, you are regularly reporting
succesful builds for this target...
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-08
01:07 ---
Subject: Re: libstdc++-v3 compile error - conflicts with previous using
declaration
> Dave, can you have a look to this PR? AFAIK, you are regularly reporting
> succesful builds for this target...
See a c
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-08 01:14 ---
This patch seems fairly reasonable to me, though not perfect.
It will reset errno if stat() fails, which, while probably not
fatal, is still a bit troubling.
--
tromey at gcc dot gnu dot org changed:
W
--- Comment #8 from tromey at gcc dot gnu dot org 2007-01-08 01:21 ---
What is the status of this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-08 01:36 ---
I've submitted a patch.
As explained in the message, I think we should just document
the current behavior, not change it.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-08 01:41 ---
Confirmed with svn trunk.
You don't have to worry about the triplets in this case.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-08 01:48 ---
The -MT documentation is in error, that is PR 15185.
I didn't find this text confusing since, I suppose, I'm used to
"basename" referring to what the basename(1) program does.
--
tromey at gcc dot gnu dot org cha
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-08 01:54 ---
Confirmed.
I'm inclined to agree that we should disallow -MG in this situation.
Perhaps this is best done in c-opts.c:sanitize_cpp_opts()
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-08 02:14 ---
I looked into this a little bit tonight.
The bug here is that the code for #error calls
cpp_output_line, which ends up calling
cpp_error_with_line when transforming the trigraph.
So, the trigraph warning is emitted b
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-08 02:18 ---
With svn trunk, the .d file ends up in /tmp regardless of whether
preprocessing succeeds or fails.
This is also the case for the GCC 4.1.1 that shipped in FC 5.
So, I think this bug was probably fixed at some point in
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-08 02:22 ---
I'm going to close this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-08 02:24 ---
What is the status of this?
The patch looks reasonable to me (though I can't approve it)
but seems to have been dropped.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-08 04:06 ---
The problem here is that the type of the component_ref is the same as the int
so when we fold the x.i+0 into x.i, we don't have a NOP_EXPR.
Janis,
Can you do a regression hunt on this bug?
Thanks,
Andrew
--
pi
--- Comment #16 from tkoenig at gcc dot gnu dot org 2007-01-08 07:45
---
I was just looking at the gfc_simplify_transfer function, and
it appears it isn't called for the original test program.
Any idea why?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
39 matches
Mail list logo
