--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-04-27 07:01 ---
Hi Roger,
I'm adding you to the CC list on this PR on Paul T.'s
suggestion. You are one of our dependency experts, so
maybe you can do something about this :-)
Thomas
--
tkoenig at gcc dot gnu dot org
--- Comment #5 from chat95 at mac dot com 2007-04-27 08:01 ---
Andrew Pinski: It seems ldconfig doesn't detect 4.2 libstdc++.
I removed gcc-4.1 and gcc-4.2 compiled executable now find correct version
of libstdc++...
marked as worksforme.
thanks for your attention.
--
chat95 at mac
--- Comment #6 from martin at mpa-garching dot mpg dot de 2007-04-27 08:02
---
I confirm that this is fixed for me on mainline.
Is the patch non-invasive enough for a backport to 4.2 (possibly after the
4.2.0 release)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25923
I did some analysis of why gfortran does badly at the gas_dyn benchmark of the
Polyhedron benchmark suite. See my analysis at
http://gcc.gnu.org/ml/fortran/2007-04/msg00494.html
In short, GCC should use reciprocal and reciprocal square root instructions
(available in single precision for SSE and
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-27 09:49 ---
No, because PR 31699 is triggered by -ftree-vectorize.
Well, at least with today's GCC plus the patch in PR 31699, it does not crash
anymore. I will do some more checks to make sure I don't miss something.
--
--- Comment #5 from pcarlini at suse dot de 2007-04-27 09:54 ---
Please, do not lump together many different issues in a single report, that's
totally confusing. This one is about configury vs locale model and it's an
enhancement PR, because it's only about user friendlyness (most of
It appears the following didn't get fixed when you fixed PR31078 and
PR31103. This is one of these annoying case where the warning doesn't show
up all the time, but if you run gcc over it long enough you'll see it:
g++ -O3 -fPIC -DNDEBUG -Iagg/include -c -o agg/src/agg_vcgen_stroke.o
--- Comment #1 from tbm at cyrius dot com 2007-04-27 10:04 ---
Created an attachment (id=13454)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13454action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31724
--- Comment #35 from pcarlini at suse dot de 2007-04-27 10:04 ---
(In reply to comment #34)
Also, if you argue against __try/__catch, why do you already use
__throw_exception_again, which is just a different name for throw? If you can
use this, you can as well use __try and __catch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-27 10:13 ---
I actually think it is more related to PR 28341 than the other one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-27 10:16 ---
Comment by Richard Guenther in the same thread:
-
I think that even with -ffast-math 12 bits accuracy is not ok. There is
the possibility of doing another newton iteration step to improve
accuracy,
In the following program, at line 68, array zsymelr is overwritten during the
assignment to zsymelr. The output contains 'This should not happen' when the
bug is present. Other compilers produce correct output, for which the last line
reads 'symelr-symel'
$ gfortran -v
Using built-in specs.
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2007-04-27 10:34
---
Created an attachment (id=13455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13455action=view)
failing program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-27 10:42 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-27 10:45 ---
Note that SSE can vectorize only the float precision variant, not the double
precision one. So one needs to carefuly either disable vectorization for the
double variant to get reciprocal code or the other way
$ cat minloc.f90
PRINT *, MINLOC((/ 42, 23 /), DIM=1, MASK=.FALSE.)
PRINT *, MINVAL((/ 42, 23 /), DIM=1, MASK=.FALSE.)
END
$ gfotran-4.2 -g -Wall minloc.f90 ./a.out
1
2147483647
F2003, 13.7.78, MINLOC, Result Value:
Case (ii) The result of MINLOC (ARRAY, MASK = MASK) is a rank-one
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-27 11:22 ---
MINVAL/MAXVAL are ok.
F2003, 13.7.79, MINVAL, Result Value:
Case (i): [...] If ARRAY has size zero and type integer or real, the result
has the value of the positive number of the largest magnitude
--- Comment #3 from jb at gcc dot gnu dot org 2007-04-27 11:27 ---
(In reply to comment #2)
Note that SSE can vectorize only the float precision variant, not the double
precision one. So one needs to carefuly either disable vectorization for the
double variant to get reciprocal code
--- Comment #4 from jb at gcc dot gnu dot org 2007-04-27 11:29 ---
(In reply to comment #3)
1. Convert to single precision
2. Calculate rcp(s|p)s or rsqrt(p|s)s
3. Refine with newton iteration
vs. just using div(p|s)d or sqrt(p|s)d?
This should be
1. Convert to single precision
--- Comment #5 from ubizjak at gmail dot com 2007-04-27 11:35 ---
(In reply to comment #3)
Created an attachment (id=13450)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13450action=view) [edit]
This patch fixes the testcase from comment #2 and Polyhedron rnflow failure in
both
In the following testcase with -O1, dce removes the bla call, thus
making the otherwise infinite loop terminate:
static void bla(void *label)
{
goto *label;
}
int main (void)
{
l1:
bla (l1);
return 0;
}
--
Summary: Functions with non-local gotos are considered not to
--- Comment #5 from jb at gcc dot gnu dot org 2007-04-27 12:01 ---
With the benchmarks at http://www.hlnum.org/english/doc/frsqrt/frsqrt.html
I get
~/src/benchmark/rsqrt% g++ -O3 -funroll-loops -ffast-math -funit-at-a-time
-march=k8 -mfpmath=sse frsqrt.cc
~/src/benchmark/rsqrt%
--- Comment #36 from pcarlini at suse dot de 2007-04-27 12:04 ---
Humm, probably, however, I'm finally getting Gaby's point about the front-end
involvement (sorry, I wasn't really paying attention to this PR until a few
days ago): if we implement something like Howard's change we would
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-27 12:04 ---
I think this is ipa-pure-const again:
Function found to be const: bla
Function found to be const: main
and DCE removes pure/const function calls. (We should also not CSE such
calls)
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-27 12:09 ---
You are right, they are only available for float precision.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #7 from burnus at gcc dot gnu dot org 2007-04-27 12:41 ---
(float) time for 1.0 / sqrt = 5.96 sec (res = 2.845058125000e+05)
(float) time for rsqrt = 2.49 sec (res = 2.23602250e+05)
(double) time for 1.0 / sqrt = 7.35 sec (res = 5.9926234364635509e+05)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-27 12:42 ---
Subject: Bug 31715
Author: rguenth
Date: Fri Apr 27 12:42:43 2007
New Revision: 124216
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124216
Log:
2007-04-27 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-27 12:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-27 13:16 ---
The problem is:
if(0) { /* find index */
else
{
pos.1 = 0;
}
D.1356 = (int4) ((unnamed-unsigned:32) pos.1 + 1);
As C and the internal tree have array indexes starting at one, the
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2007-04-27
13:26 ---
How many of the changes made so far to trunk (which have reduced the stack
usage from 20K to 5K) have been backported into gcc 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #37 from hhinnant at apple dot com 2007-04-27 14:15 ---
Thanks for looking at this issue.
Also consider Andrew's point about useful diagnostics, for example from comment
#4. And the followup to that point in #33 which includes field experience on
how other compilers deal
--- Comment #38 from pcarlini at suse dot de 2007-04-27 14:22 ---
(In reply to comment #37)
Thanks for looking at this issue.
Also consider Andrew's point about useful diagnostics, for example from
comment #4.
Of course, if/when the front-end is changed as I was outlining,
--- Comment #39 from l dot lunak at suse dot cz 2007-04-27 14:41 ---
I find the reasoning that this change should not be done because somebody
possibly might be using the libstdc++'s different semantics of try/catch rather
weak, for several reasons:
- it's not documented anywhere, at
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-27 14:44 ---
Subject: Bug 30978
Author: rguenth
Date: Fri Apr 27 14:43:42 2007
New Revision: 124217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124217
Log:
2007-04-27 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-27 14:44 ---
Subject: Bug 30965
Author: rguenth
Date: Fri Apr 27 14:43:42 2007
New Revision: 124217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124217
Log:
2007-04-27 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-27 14:56 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
--- Comment #10 from uweigand at gcc dot gnu dot org 2007-04-27 14:59
---
Subject: Bug 30761
Author: uweigand
Date: Fri Apr 27 14:59:21 2007
New Revision: 124219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124219
Log:
PR middle-end/30761
* reload1.c
--- Comment #11 from uweigand at gcc dot gnu dot org 2007-04-27 15:03
---
(In reply to comment #8)
Ulrich, in response to your question in Comment #6, yes, this bug appears in
4.1 and 4.2, not just in 4.3. So, if you think it's safe to backport the
reload patch, it would be nice to
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-27 15:06 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
When --enable-java-maintainer-mode is specified, libgcj's configure should pass
--enable-regen-headers --with-javah=maintainer gjavah
--with-classpath=$srcdir/classpath/lib to classpath/configure, so that GNU
Classpath's JNI headers are rebuilt with the maintainer gjavah against the
bootstrap
--- Comment #1 from sje at cup dot hp dot com 2007-04-27 15:31 ---
I am seeing this too. My last good version was r124171. My failing version is
r124207.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-27 15:47 ---
The program is broken / invalid:
function lenstr(s)
character*(*) s
do 1 l=ll,1,-1
if (s(l:l).ne.' ') goto 2
1 continue
Question: What value has ll ? 0, 325, -4326 ?
Depending on the
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-27 15:59 ---
Patch. Dump looks ok. Needs some testcases plus checking of the library
version.
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (Revision 124216)
--- Comment #3 from KnowlesPJ at Cardiff dot ac dot uk 2007-04-27 16:13
---
I don't agree with this analysis, as ll is certainly defined in char3.f as
attached -
ll=len(s)
Please try with the program exactly as supplied!
Yes, you are right, this function is the same as len_trim but all
--- Comment #2 from sje at cup dot hp dot com 2007-04-27 16:29 ---
It looks like these failures start with version 124203, a patch by Zdenek
Dvorak to speed up tree cfg clean up.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #5 from irving at cs dot stanford dot edu 2007-04-27 16:45
---
Is there any chance of activity on this bug?
It would be wonderful to have a warning for this
case, since these bugs can be extremely annoying to find.
If the infrastructure supports it, the ideal way to
--- Comment #5 from tprince at computer dot org 2007-04-27 17:02 ---
According to my test of Dorit's updated patch,
the following are now PASS:
vect-iv-9.c
vect-iv-4.c
pr30771.c
The patch changed FAIL to XFAIL for the following
vect-reduc-dot-u16b.c
vect-widen-mult-u16.c
erase member functions of std::map class template do not conform to standard:
std::map...::erase(iterator) and std::map...::erase(iterator, iterator)
both return void when they should return iterator (23.3.1):
bits/stl_map.h:444
void
erase(iterator __position)
{
--- Comment #4 from jakub at gcc dot gnu dot org 2007-04-27 17:23 ---
Yeah, this is fixed by the PR31038 patch and that patch fixes this even
on gcc-4_1-branch. But the original PR31038 testcase still ICEs on 4.1 even
with PR31038 patch.
--
--- Comment #1 from pcarlini at suse dot de 2007-04-27 17:26 ---
I have the standard in front of me, both the printed version and the electronic
version, and certainly you are wrong, both overloads return void.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #9 from pault at gcc dot gnu dot org 2007-04-27 17:27 ---
(In reply to comment #8)
The patch below seems too simple to be true - it fixes the problem, I guess it
will regtest but we will have to see what it does to performance. If you look
at it, it is potentially rather
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-27 17:42 ---
Created an attachment (id=13456)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13456action=view)
Test case
Writing test cases first helps!
I need go back to the drawing board as the pos = pos + 1 is not added
--- Comment #4 from tromey at gcc dot gnu dot org 2007-04-27 17:44 ---
Dan Berlin said if you log in first you should be able to attach things.
I downloaded rhino 1_6r5 from: http://www.mozilla.org/rhino/download.html
Then I tried the .class you sent me. I tried with gcj 4.1 (from the
--- Comment #10 from roger at eyesopen dot com 2007-04-27 18:20 ---
Paul's fix looks correct to me. It appears that when the #if 0 was added
to disable broken loop shifting at some point in the distant past, the critical
functionality.
if (nDepend)
break;
was accidentally
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-27 18:59 ---
(Slabs oneself because of deleting important lines while deleting only
comments.)
Thanks for being persistent!
Reduced test case, should print twice X,Y but prints (once) ,Y.
The problem is that for
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #2 from leg0 at hot dot ee 2007-04-27 19:26 ---
According to the working drafts
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2009.pdf and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf I am right.
But since they are drafts I may still be
--- Comment #3 from pcarlini at suse dot de 2007-04-27 19:31 ---
Working drafts are working drafts, and therefore are about the *next* standard,
not the current one, C++03. When the new standard will be out, and we'll
provide a conforming implementation, breaking the ABI, we'll provide
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-04-27 19:33 ---
I see it on sparc-sun-solaris2.10 as well.
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01390.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fitzsim at redhat dot com 2007-04-27 19:59 ---
Also, classpath/include/Makefile.am needs to only list headers actually built
in the libgcj build, and the -force option should be passed to the gjavah
calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31728
The following code should compile. With gcc 4.3 it does not.
templatetypename Iter struct match_context { };
templatetypename BidIter
struct match_state
{
typedef match_contextBidIter match_context;
};
--
Summary: nested typedef to template of same name rejected
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-04-27 20:16 ---
One should also check the library version of MIN/MAXLOC.
I'll do that. This is an area that I am working on anyway
(PR 30694).
Thanks for providing the test case, btw. It is quite
thorough :-)
--
tkoenig
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-27 20:16 ---
No, the error message is correct. You change the meaning of match_context in
the class.
Doing:
typedef ::match_contextBidIter match_context;
Fixes the source to be valid C++. Note C++ does not really require
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-04-27 21:00 ---
Created an attachment (id=13457)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13457action=view)
Test case for the library functions
The library function appears to be ok. Here is the test
case
This is not bug 5035.
[EMAIL PROTECTED] Bug2]$ cat bb.f90
subroutine SetupRadii(N)
integer,intent(in)::N
integer::i,j
write(*,*)(/(i,i=1,N)/)
write(*,*)(/(j,j=1,5)/)
end subroutine SetupRadii
[EMAIL PROTECTED] Bug2]$ gfortran -Wall -O1 -v -c bb.f90
Using built-in specs.
Target:
--- Comment #2 from eric dot niebler at gmail dot com 2007-04-27 21:24
---
Yep, thanks. According to Doug Gregor, this case is covered in the first para
of
[basic.scope.class]. My bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31730
--- Comment #8 from steven at gcc dot gnu dot org 2007-04-27 21:43 ---
I suppose this is something that requires new builtins?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ian at gcc dot gnu dot org 2007-04-27 21:47 ---
Subject: Bug 31710
Author: ian
Date: Fri Apr 27 21:47:24 2007
New Revision: 124237
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124237
Log:
./:
PR middle-end/31710
* tree.c
--- Comment #5 from ian at gcc dot gnu dot org 2007-04-27 21:49 ---
Subject: Bug 31710
Author: ian
Date: Fri Apr 27 21:48:55 2007
New Revision: 124238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124238
Log:
./:
PR middle-end/31710
* tree.c
--- Comment #6 from ian at airs dot com 2007-04-27 21:50 ---
Fixed on mainline and 4.2 branch.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-27 22:03 ---
I looked at this at some time and in priciple it doens't require it. For the
vectorized call we'd need to support target dependent pattern vectorization,
for the scalar case we would need a new optab to handle 1/x
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-27 22:18 ---
*** Bug 31731 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-27 22:18 ---
*** This bug has been marked as a duplicate of 29458 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from olga at il dot ibm dot com 2007-04-27 22:31 ---
The fix was submitted
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01578.html
and committed to mainline 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31617
--- Comment #7 from kkojima at gcc dot gnu dot org 2007-04-27 22:36 ---
The testcase fails with 3.4.6, but doesn't fail with 4.0 and later
compilers. So I'd like to close this PR as WONTFIX because 3.4 was
frozen.
--
kkojima at gcc dot gnu dot org changed:
What
--- Comment #9 from olga at gcc dot gnu dot org 2007-04-27 22:41 ---
FIXED.
--
olga at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-27 23:52 ---
trans-expr.c's gfc_conv_variable contains:
/* Special case for assigning the return value of a function.
Self recursive functions must have an explicit return value. */
if (return_value
--- Comment #6 from tprince at computer dot org 2007-04-27 23:56 ---
I retyped the xfail instruction after applying the patch, and now
gcc.dg/vect/no-section-anchors-vect-69.c
shows XFAIL as intended, with the patch Dorit posted yesterday.
My patch must have been corrupted with
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-04-28 00:23 ---
Created an attachment (id=13458)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13458action=view)
patch for 3.4
This was fixed on 4.1. I'd like to close this PR as FIXED
because 3.4 and 4.0 are frozen now.
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-04-28 00:24 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-28 00:36 ---
This code is undefined
Take a look at the manual:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Labels-as-Values.html
You may not use this mechanism to jump to code in a different function. If you
do that, totally
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-28 00:37 ---
Oh and this goto is considered not a non-local goto, it is just considered a
computed goto. A non-local goto is only with nested functions. Like:
int main (void)
{
__label__ l1;
void bla(void)
{
goto l1;
}
l1:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-28 00:40 ---
By the way non local gotos are documented at:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Nested-Functions.html
I really guess nobody actually reads the documentation (yes we can improve it
but even then people
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-28 00:46 ---
*** This bug has been marked as a duplicate of 31598 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-04-28 00:46 ---
*** Bug 31708 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-28 00:48 ---
Confirmed, I noticed this also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-04-28 01:07 ---
Subject: Bug 31701
Author: kkojima
Date: Sat Apr 28 01:07:40 2007
New Revision: 124248
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124248
Log:
PR target/31701
* config/sh/sh.c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-28 01:31 ---
Not a bug as already explained.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-28 01:34 ---
BTW I think I see a bug created by this change: with -Os x86_86 ABI will be
violated - arrays larger than 16 bytes will still be aligned only to 4 bytes
because if's are in wrong order. shouldn't they be swapped?
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-28 01:35 ---
Actually static builds of libgcj are pretty much broken with a valid ABI :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-04-28 01:37 ---
I think this needs a real specifications and not just saying the reording can
happen (as an asside there are two kinds of derived types in Fortran, one
called sequence and the other normal, the sequence one is what
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-28 01:41 ---
This also happens on the 4.2 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-28 01:44 ---
Except how is stdint.h is in scope, it only includes stdarg.h and signal.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31341
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-04-28 03:03
---
Subject: Bug 31532
Author: jvdelisle
Date: Sat Apr 28 03:03:21 2007
New Revision: 124252
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124252
Log:
2007-04-27 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-04-28 03:04
---
Subject: Bug 31532
Author: jvdelisle
Date: Sat Apr 28 03:04:35 2007
New Revision: 124254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124254
Log:
2007-04-27 Jerry DeLisle
PR libfortran/31532
1 - 100 of 121 matches
Mail list logo
