--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-30 06:49 ---
> FM403.f, FM900.f, and FM903.f fail to compile.
> I have confirmed this regression is caused by.
>
> 2050 FORMAT(2PF8.3,-2PE9.4,F9.4,0PF9.4,9X,-2PE9.4,F9.4)
> 1
> Er
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-30 05:14
---
Examples:
FM403.f:859.35:
2050 FORMAT(2PF8.3,-2PE9.4,F9.4,0PF9.4,9X,-2PE9.4,F9.4)
1
Error: Unexpected element in format string at (1)
FM403.f:860.20:
REA
FM403.f, FM900.f, and FM903.f fail to compile.
I have confirmed this regression is caused by.
http://gcc.gnu.org/viewcvs?view=rev&revision=126107
Adding Tobias to cc list
--
Summary: [4.3 Regression] Miscompilation of NIST testsuite
Product: gcc
Version: 4.3.0
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-30 05:03
---
There is an off by 1 error in the calculation of the number of digits. This is
a latent bug uncovered by Janne's patch. Patch is on its way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
--- Comment #4 from patchapp at dberlin dot org 2007-06-30 03:10 ---
Subject: Bug number PR30940
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-06/msg02128.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #37 from ghazi at gcc dot gnu dot org 2007-06-30 02:22 ---
Run this in a.17.1.i targetted to sparc-sun-solaris2.10 with
--enable-checking=yes,fold and:
cc1 -fpreprocessed a.17.1.i -quiet -dumpbase a.17.1.c -mcpu=v9 -auxbase-strip
a.17.1.s -version -fopenmp -fno-show-column -
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-30 02:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #36 from ghazi at gcc dot gnu dot org 2007-06-30 02:16 ---
I tried --enable-checking=yes,fold on sparc-sun-solaris2.10, bootstrap works
but I'm still getting a few extra failures. Here are two testresults from the
same checkout, one regular and one with fold checking turned
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-30 02:10
---
I was wondering if we could do something like:
/* If we have a definition of INCOMING_RETURN_ADDR_RTX, assume that
the rest of the DWARF 2 frame unwind support is also provided. */
#if !defined (DWARF2_UNWIND_
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-30 02:05
---
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:[Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]
Re: Fwd: INCOMING_RETURN_ADDR_RTX i
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-30 00:50
---
I agree, that's why I said I was not sure. I am thinking this is pretty odd.
I am going to test snprintf to see if its broken. sprintf works fine as is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
--- Comment #4 from kargl at gcc dot gnu dot org 2007-06-30 00:32 ---
(In reply to comment #3)
> This appears to fix it but I am not sure yet. More testing.
>
> */
> #ifdef HAVE_SNPRINTF
> - snprintf (buffer, sizeof (buffer), "%+-#" STR(MIN_FIELD_WIDTH) ".*"
> + snprintf (buffer
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-06-30 00:30
---
As mentioned many times, libgcc is correct and the issue with the libgcc is a
kernel issue. Yes GCC should not be emitting udivid3 in the case of the loop
but that is a different bug which is still open.
--
pi
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-06-30 00:29
---
Hello anyone in here? I guess you did not see my comment about the code gen
issue is going to be fixed. The issue with the library is a different problem
and not really an GCC issue and that if the programer uses
--- Comment #24 from malitzke at metronets dot com 2007-06-30 00:22 ---
Mr. Torvalds has already answered in comment 1
--
malitzke at metronets dot com changed:
What|Removed |Added
---
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-30 00:20
---
This appears to fix it but I am not sure yet. More testing.
Index: write.c
===
--- write.c (revision 126131)
+++ write.c (working copy)
@@
--- Comment #23 from malitzke at metronets dot com 2007-06-30 00:18 ---
Segher was mentioned twice. First, according to my research he is not a kernel
maintainer as implied in comments 4 and 9. He is actuallu Segher Boessenkool, a
GCC maintainer, inactive since 2005-02-01, his latest em
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-30 00:05
---
I have traced to this patch, the change in write.c:
http://gcc.gnu.org/viewcvs?view=rev&revision=125100
Added Janne to cc
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-06-29 23:57
---
When I am saying GCC is doing the correct thing, I am talking about the library
issue and not about the code gen issue (the code gen issue is filed in a
different bug and will be fixed, it just takes time though yo
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-06-29 23:55
---
How many times do I and others, GCC is doing the correct thing?
If you want to ping someone, go talk to Linus.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from malitzke at metronets dot com 2007-06-29 23:53 ---
Ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-06-29 23:51 ---
Think I got all the pieces for this one ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-29 23:41
---
Confirmed. I will take this one. Hmm.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
Hi,
the following code:
program gfcbug66
real(8) :: x = 1.0e-100_8
write (*,'(1X,2E12.3)')x, 2 * x
write (*,'(1X,1P,2E12.3)') x, 2 * x ! Second printed number is wrong
end program gfcbug66
produces:
0.100E-99 0.200E-99
1.000-100 2.000E-10
but it should be
0.100E-99
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-29 23:23
---
Currently inline_1.f90 in gfortran.fortran-torture/compile is passing because
the error in the print statement is only giving a warning.
Patch testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32545
In this example:
int g(void);
void f(int *p, int i)
{
p[i] = g();
p[i + 2] = g();
p[i + 10] = g();
p[i + 100] = g();
}
the common expression of (p + i * 4) isn't completely eliminated.
It works with the current stable Debian release (gcc (GCC) 4.1.2 20061115), but
--- Comment #19 from schwab at suse dot de 2007-06-29 22:34 ---
There is no violation of any C standard.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #18 from malitzke at metronets dot com 2007-06-29 22:19 ---
As I am clearly rejected by the GCC insiders in my attempts to help make the C
compiler more attuned to the spirit of the C99 committee; I am now forced to
alert the user community of what is happening with a near
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-29 22:09 ---
[Compile-time checking]
I think this was fixed a while ago - at least for contained procedures. If not
it is then definitely fixed (for contained procedures) by my patch for PR30940:
"Character length of actual argu
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-06-29 21:45
---
1) The compiler needs a support library to implement all required features in
the standard.
2) That library is libgcc.
3) Linux kernel has its own support library for these functions
4) The linux kernel support lib
--- Comment #16 from malitzke at metronets dot com 2007-06-29 21:42 ---
A treaty is a bilateral agreement. No something shoved down one Side throat.
The worse I look the more I accomplish for others than GCC fanatics
--
malitzke at metronets dot com changed:
What|Rem
--- Comment #1 from spark at gcc dot gnu dot org 2007-06-29 21:41 ---
Below is the email I sent to Jim Wilson asking for help
with the analysis of the bug.
Hi Jim,
This is an analysis of a correctness bug on ia64,
which root cause has to do with your code.
After dataflow merg
SPEC CPU2000 applu and fma3d fail at runtime when compiled with -O3.
--
Summary: Runtime failure in SPEC CPU2000 benchmark fma3d and
applu
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priorit
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-29 21:28 ---
Seems to be fixed in trunk:
$> gfortran-svn -g -Wall -fopenmp pr32551.f90 && ./a.out
omp_get_nested()= F
2 2 2 2
$> gfortran-svn -v
gcc version 4.3.0 20070628 (experimenta
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-29 21:20
---
> A standard is a __treaty__ (contract) between implementor and programmer.
And in our implementation, there is a library for support functions. If you
don't see that, then please stop your rants. Your rants act
--- Comment #14 from malitzke at metronets dot com 2007-06-29 21:14 ---
The first two sentences of your comment was never disputed by either myself nor
from how I read Mr Torvald's comment.
The only thing under dispute is the completely unwarrented trnasformation of a
subtraction into
--- Comment #17 from rask at sygehus dot dk 2007-06-29 21:10 ---
Fixed for both m32c and avr, so closing.
--
rask at sygehus dot dk changed:
What|Removed |Added
--- Comment #7 from zadeck at naturalbridge dot com 2007-06-29 21:02
---
Subject: Re: [4.3 Regression] ICE in df_refs_verify,
at df-scan.c:4065
hubicka at gcc dot gnu dot org wrote:
> --- Comment #6 from hubicka at gcc dot gnu dot org 2007-06-29 20:15
> ---
> Paolo's rumor
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-29 21:00 ---
Bill, thanks for your report! Here's a slightly simplified testcase:
$> cat pr32550.f90
integer, pointer, save :: ptr
integer, target :: targ
!$omp threadprivate(ptr)
!$omp parallel shared(targ)
!$omp single
ptr =>
--- Comment #13 from dgregor at gcc dot gnu dot org 2007-06-29 20:25
---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #12 from dgregor at gcc dot gnu dot org 2007-06-29 20:21
---
Subject: Bug 31724
Author: dgregor
Date: Fri Jun 29 20:21:41 2007
New Revision: 126124
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126124
Log:
2007-06-29 Douglas Gregor <[EMAIL PROTECTED]>
PR
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-06-29 20:19 ---
The testcase works for me on current mainline with sharing checking patch on
x86_64-linux, but since the target triplet is not specified, can you double
check, please, that the bug is gone?
Honza
--
http://gcc.
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-06-29 20:15 ---
Paolo's rumor is correct, Indeed. I somehow lost track in patches that was or
wasn't approved or tested. I've comited the fix now.
--
hubicka at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from aesok at gcc dot gnu dot org 2007-06-29 20:15 ---
Fixed for avr target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
--- Comment #5 from hubicka at gcc dot gnu dot org 2007-06-29 20:13 ---
Subject: Bug 32372
Author: hubicka
Date: Fri Jun 29 20:13:41 2007
New Revision: 126122
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126122
Log:
PR middle-end/32372
* cse.c (cse_insn): Avoi
--- Comment #15 from aesok at gcc dot gnu dot org 2007-06-29 20:06 ---
Subject: Bug 32335
Author: aesok
Date: Fri Jun 29 20:05:56 2007
New Revision: 126121
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126121
Log:
PR target/32335
* config/avr/avr.c: Include data
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-29 20:05
---
Since I partly discovered this, I will see what I can do.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-29 19:45 ---
I don't think this is a bug.
So we have in one TU:
typedef struct {
char x[10];
} Argument;
And in the other:
typedef struct {
char x[20];
} Argument;
--- cut ---
IIRC from my
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-06-29 19:43 ---
Yes, this is fixed.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-06-29 19:39
---
Subject: Bug 32456
Author: jvdelisle
Date: Fri Jun 29 19:39:21 2007
New Revision: 126119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126119
Log:
2007-06-29 Jerry DeLisle <[EMAIL PROTECTED]>
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #4 from zadeck at naturalbridge dot com 2007-06-29 19:34
---
there is a rumor being circulated by bonzini that one of honza's unsharing
patches fixes this. However, this fails on the current truck.
One positive note is that if you add in honza's illegal sharing detector, i
--- Comment #5 from mark at codesourcery dot com 2007-06-29 19:29 ---
Subject: Re: [4.3 Regression] ICE in build2_stat,
at tree.c:3074
pinskia at gcc dot gnu dot org wrote:
> --- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 19:27
> ---
> Mark,
> Even though th
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 19:27 ---
Mark,
Even though this has only showed up in Fortran code correctly. I could make
a C testcase where it fails. The Fortran code looks simplier because of arrays
in Fortran are way simplier than in C.
Do you want
--- Comment #3 from bonzini at gnu dot org 2007-06-29 19:26 ---
CCing Honza, he had a patch for this bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #17 from bonzini at gnu dot org 2007-06-29 19:25 ---
And that's why I left it assigned to me. I'll work on it next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #8 from andreast at gcc dot gnu dot org 2007-06-29 19:16
---
With the patch referenced in #7 results on i686-darwin
=== gfortran Summary ===
# of expected passes18372
# of unexpected failures16
# of expected failures 8
# of unsu
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-29 19:09 ---
Fixed in trunk, no backport. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-29 19:06 ---
Subject: Bug 31580
Author: dfranke
Date: Fri Jun 29 19:05:58 2007
New Revision: 126117
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126117
Log:
gcc/fortran:
2007-06-29 Daniel Franke <[EMAIL PROTECTED]>
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
--- Comment #16 from echristo at apple dot com 2007-06-29 19:00 ---
No, we shouldn't close it until we can get the compiler building on ppc with
-mdynamic-no-pic.
--
echristo at apple dot com changed:
What|Removed |Added
---
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
Description:
This test case tries to show that
the following statement found in the OpenMP API Version 2.5 May 2005 on p.29
lines 21-24 is true:
"When a thread executing inside an active parallel region encounters a parallel
construct, the new team which is created will consist of only the encoun
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-06-29 18:52
---
There is nothing wrong with langhooks per se.
The problem is langhooks that influence the interpretation of the IR, not
langhooks that are used to *create* the IR.
--
mmitchel at gcc dot gnu dot org changed:
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32431
--- Comment #2 from patchapp at dberlin dot org 2007-06-29 18:50 ---
Subject: Bug number PR31580
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-06/msg02115.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-06-29 18:49
---
Andrew, do you want to convert to sizetype or to ptrdiff_t? Does it matter?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32385
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32384
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
Description:
The test case checks that
the following statement found in the section 2.8.4.2 copyprivate clause
of the OpenMP API Version 2.5 May 2005 (p. 86 lines 22-24) will work:
"If the list item is a pointer, then in all other threads in the team,
the list item becomes pointer associated (as
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32338
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32337
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32303
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32295
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32269
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32260
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32253
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32252
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32251
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32241
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32238
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32135
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32128
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32127
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
1 - 100 of 180 matches
Mail list logo
