--- Comment #1 from chat95 at mac dot com 2007-03-01 08:00 ---
Created an attachment (id=13129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13129&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31006
--- Comment #2 from chat95 at mac dot com 2007-03-01 08:01 ---
I used following compiler:
% gcc42 -v
Using built-in specs.
Target: i386-portbld-freebsd6.2
Configured with: ./..//gcc-4.2-20070110/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/
--- Comment #3 from chat95 at mac dot com 2007-03-01 08:06 ---
1.
// long double PI * PI + IP
ld_a = ld_b = PI;
part becomes:
movl$560513024, %eax
movl$-921707870, %edx
movl$16384, %ecx
This number is equivalent to:
0x4000c90fdaa22168c00
--- Comment #38 from baldrick at free dot fr 2007-03-01 08:18 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> ... The problem
> is that the value of arg1, a constant, is not in the
> range of its own type! ...
It seemed clear to me last night why this is a problem,
--- Comment #13 from burnus at gcc dot gnu dot org 2007-03-01 08:19 ---
Subject: Bug 30865
Author: burnus
Date: Thu Mar 1 08:19:09 2007
New Revision: 122423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122423
Log:
2007-03-01 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #2 from paolo at gcc dot gnu dot org 2007-03-01 09:03 ---
Subject: Bug 31005
Author: paolo
Date: Thu Mar 1 09:03:30 2007
New Revision: 122424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122424
Log:
2007-03-01 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #14 from burnus at gcc dot gnu dot org 2007-03-01 09:44 ---
Subject: Bug 29820
Author: burnus
Date: Thu Mar 1 09:43:53 2007
New Revision: 122427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122427
Log:
fortran/
2007-03-01 Paul Thomas <[EMAIL PROTECTED]>
B
--- Comment #11 from burnus at gcc dot gnu dot org 2007-03-01 09:44 ---
Subject: Bug 30660
Author: burnus
Date: Thu Mar 1 09:43:53 2007
New Revision: 122427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122427
Log:
fortran/
2007-03-01 Paul Thomas <[EMAIL PROTECTED]>
B
--- Comment #12 from burnus at gcc dot gnu dot org 2007-03-01 09:45 ---
Backported to 4.2, not part of 4.1 => FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #39 from rguenth at gcc dot gnu dot org 2007-03-01 09:50
---
One key point to notice is that the transformation looks at ARG0 op CST where
arg0 and cst don't necessarily have to have the same type (arg0 is reduced from
op0 by STRIP_SIGN_NOPS), so effectively this folds
(B
--- Comment #3 from aph at gcc dot gnu dot org 2007-03-01 11:56 ---
.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from aph at gcc dot gnu dot org 2007-03-01 11:57 ---
.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
#include
#include
int main()
{
uint64_t ui4 = ~((1ULL << 63ULL) >> 3ULL);
union {
uint64_t i64;
struct {
uint32_t lo;
uint32_t hi;
} i32;
} ui5;
ui5.i64 = ui4;
printf( "%llx %x\n", ui4, ui5.i32.hi );
return 0;
}
Return efff efff
(instead of 7ff
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-01 12:22 ---
What is the expected output of your testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31006
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-01 12:27 ---
With gcc 4.1.2 and your testcase fixed to use %f for the double argument printf
I get
[EMAIL PROTECTED]:/tmp> gcc -o t t.c -m32
[EMAIL PROTECTED]:/tmp> ./t
long double = 3.141592653589793238512808959
--- Comment #1 from hidden_peak at mail dot ru 2007-03-01 12:30 ---
> (instead of 7fff 7fff)
Correct should be fff and fff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31007
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-01 13:24 ---
Consider it done. Thanks for the reminder. I should click on "My Bugs" more
often.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
When compiling with optimization, it is possible to assign the value of one
float variable to another, and then have the latter value compare unequal to
the former. Take the following (contrived) testcase:
extern float sqrtf(float);
volatile int foo(int n) {
float a = sqrtf(n);
volatile fl
--- Comment #2 from brett dot albertson at stratech dot com 2007-03-01
13:44 ---
(In reply to comment #1)
> Could you try to bootstrap the compiler from clean build directory?
>
> Could you look into g++.log and post some errors?
> (Please note that there is no ICE, so it looks like a
--- Comment #4 from ubizjak at gmail dot com 2007-03-01 13:47 ---
Current mainline produces really horrible code:
.L4:
movl(%edx), %ebx
addl$1, %eax
movl4(%edx), %esi
addl$8, %edx
movl%ebx, 8(%esp)
movl%esi, 12(%esp
--- Comment #2 from schwab at suse dot de 2007-03-01 14:37 ---
Why do you think efff is wrong?
--
schwab at suse dot de changed:
What|Removed |Added
In January, there were two patches from Roger Sayle [1,2] which were quite an
improvement for me. I'd like to suggest to do the same for derived type
components. Example:
TYPE :: summed_amplitude
COMPLEX, DIMENSION(:,:), POINTER :: alm
END TYPE
SUBROUTINE summed_amplitude_init_copy(this, other)
--- Comment #3 from hidden_peak at mail dot ru 2007-03-01 14:48 ---
~((1ULL << 63ULL) >> 3ULL):
( 0001 << 63) -> 8000 (unsigned!)
(8000 >> 3 ) -> f000 (due to sign bit)
~(f000 ) -> 0fff
Right?
--- Comment #4 from schwab at suse dot de 2007-03-01 15:00 ---
Shifting unsigned numbers doesn't replicate the sign bit.
--
schwab at suse dot de changed:
What|Removed |Added
-
--- Comment #5 from hidden_peak at mail dot ru 2007-03-01 15:05 ---
Do you mean this treatment: ~((1ULL << 63ULL) >> 3ULL) -> ~(1ULL << 60ULL) ->
efff ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31007
--- Comment #6 from hidden_peak at mail dot ru 2007-03-01 15:11 ---
> Shifting unsigned numbers doesn't replicate the sign bit.
unsigned ui3 = ~((1 << 31) >> 3);
printf( "%x\n", ui3 );
give me wrong result fff ?
--
hidden_peak at mail dot ru changed:
What|Remov
--- Comment #7 from hidden_peak at mail dot ru 2007-03-01 15:13 ---
My mistake. Sorry.
--
hidden_peak at mail dot ru changed:
What|Removed |Added
Status|UNCON
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-03-01 15:30
---
Subject: Bug 16513
Author: ebotcazou
Date: Thu Mar 1 15:30:27 2007
New Revision: 122430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122430
Log:
PR other/16513
* Makefile.in: Install l
--- Comment #7 from tobi at gcc dot gnu dot org 2007-03-01 15:52 ---
Subject: Bug 29441
Author: tobi
Date: Thu Mar 1 15:52:28 2007
New Revision: 122431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122431
Log:
fortran/
Backport from trunk
PR fortran/29441
* intrinsic.c (gfc_in
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-01 16:33 ---
> I'd like to suggest to do the same for derived type components.
The point is not components or not, the point is: Known size at compile time or
not. (A different thing are arrays of derived types.)
The same tree wi
--- Comment #8 from tobi at gcc dot gnu dot org 2007-03-01 16:40 ---
Subject: Bug 29441
Author: tobi
Date: Thu Mar 1 16:40:34 2007
New Revision: 122433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122433
Log:
fortran/
Backport from trunk
PR fortran/29441
* intrinsic.c (gfc_in
--- Comment #9 from tobi at gcc dot gnu dot org 2007-03-01 16:43 ---
Fixed on all release branches.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Target M
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-01 16:43 ---
*** This bug has been marked as a duplicate of 323 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #90 from rguenth at gcc dot gnu dot org 2007-03-01 16:43
---
*** Bug 31008 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
On a 64-bit Ubuntu 6.10 system with gcc-4.2-20070228, gfortran erroneously
gives an error for good F90 code. In the code two parameter arrays are defined
then one is multiplied by a section of the other, with the section selected
with non-unit stride. An error is generated referencing the declara
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-01 16:58 ---
Tobias, I wouldn't expect gfortran to use memcpy if the array is not
continuous, as in your example.
OTOH, my naive assumption is, that given "this = other", "this(:) = other(:)"
or even "this(a:b) = other(c:d)", i
Caused by:
+2007-02-16 Geoffrey Keating <[EMAIL PROTECTED]>
+
+ * config/darwin.h (LINK_SPEC): Always pass -macosx_version_min
+ to linker.
Worked in: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00636.html
Failed with: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00652.html
--
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=31013
Calling _gfortran_internal_pack is not needed, if it is clear that the array is
contiguous. If it is further known that the called procedure uses
dimension(*), the creation of the array struct is also unnessarily.
In the following, the _gfortran_internal_pack call itself is unneeded:
external
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
I am trying to port an existing larger piece of software in C++ to a new x86_64
system. The software compiles well on ix86 systems with both gcc 3.3.3 and gcc
4.1.2 (prerelease as installed with openSuSE 10.2). However, on x86_64 with the
same openSuSE 10.2 system (so: gcc 4.1.2 prerelease), the co
--- Comment #1 from bernd dot speiser at uni-tuebingen dot de 2007-03-01
18:27 ---
Created an attachment (id=13130)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13130&action=view)
output of compile process
this is the output of the compiler with one comment added from my side
--- Comment #2 from bernd dot speiser at uni-tuebingen dot de 2007-03-01
18:44 ---
I have tried to attach the test.ii file, however it is too big (1.6 MB - must
use some of the boost/spirit template library headers). I have send the file as
an
attachment to gcc-bugs@gcc.gnu.org and hope
For the most common array assignments where the size is known at compile-time,
we already use __buildin_memcpy; but the following cases were missed:
subroutine bar(a)
implicit none
real :: a(*),b(12)
b = a(1:12)
end subroutine
subroutine bar(a,b)
implicit none
real :: a(*),b(*)
a(1:12) = b
--- Comment #7 from ian at gcc dot gnu dot org 2007-03-01 19:13 ---
Subject: Bug 23689
Author: ian
Date: Thu Mar 1 19:13:02 2007
New Revision: 122434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122434
Log:
cp/:
PR c++/23689
* decl.c (check_tag_decl): Added ne
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-01 19:15 ---
subroutine bar(a,b,n)
implicit none
integer :: n
real :: a(n,n), b(n,n)
a = b
end subroutine
For that example example, the overhead is even more obvious. One needs to run
only:
for (int i = 0; i < n*n; i++)
a[
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-01 19:22 ---
And analogously for these kinds of dummy arguments:
subroutine x(a,n)
integer :: n
real :: a(n)
interface
subroutine foo(x,n)
integer :: n
real :: x(n)
end subroutine foo
end interface
call foo(
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-01 19:26 ---
And another example for compile-time known sizes:
subroutine bar(a,n)
implicit none
integer :: n
real :: a(n),b(12)
a(1:12) = b
a(2:n) = b
! Here, n is unknown, but it is only valid if the shapes of b an a are
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |middle-end
h
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-01 19:34 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-01 19:35 ---
Fixed as shown by:
http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg00029.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-03-01 19:36 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-01 19:41 ---
(In reply to comment #2)
> Since the finer details of fortran still elude me, is it possible at all that
> in a statement as "this = other" were both shall be arrays of compatible
> shape,
> either stride may not e
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-03-01 19:43
---
At least this is not a regression wrt g77.
Interestingly enough, the following program sends g77 into
a tailspin of increasing memory usage during compilation:
program test
a = 3.0
print *,a**(-
--- Comment #3 from patchapp at dberlin dot org 2007-03-01 20:30 ---
Subject: Bug number PR c++/28253
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-03/msg00068.html
--
http://gcc.gnu.org/bugzil
There are several instances of checking for a specific machine such as
TARGET_K8 in the i386.md file. These should be changed to use feature macros
that test for the appropriate processor bits in the x86_* variables.
Assign this to me, as I'm working on a patch.
--
Summary: TARGET_{
--- Comment #23 from manu at gcc dot gnu dot org 2007-03-01 21:36 ---
Another issue that I am not sure how to fix.
Janis, could you take a look at this?
Testcase gcc/testsuite/gcc.dg/20041213-1.c is like:
/* { dg-do compile } */
/* test redeclarations with void and implicit int */
ext
There are a lot of feature test macros in the i386/x86_64 compiler of the form:
(x86_some_var & (1 << ix86_arch))
These tests could be micro-optimized, either by storing 1 << ix86_arch into a
global variable, or by having a global variable that is the result of the and
and the shift, so that a sim
--- Comment #24 from janis at gcc dot gnu dot org 2007-03-01 22:53 ---
Manuel, I'm at a conference and then travelling without regular access to test
machines, but I hope to get to this early next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
--- Comment #40 from baldrick at free dot fr 2007-03-01 23:07 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
The problem is in this transformation:
/* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries. */
X^Y may not be in the range of the type. I
--- Comment #5 from harsha dot jagasia at amd dot com 2007-03-01 23:18
---
I could reproduce this with 4.1, 4.2, 4.3 and the autovect branch (from svn) on
x86-64 (but not on x86):
obj-4.1/bin/gcc -c -ftree-vectorize -O2 oct_makes_gcc_explode.i
oct_makes_gcc_explode.i: In function âslow
--- Comment #25 from manu at gcc dot gnu dot org 2007-03-01 23:24 ---
(In reply to comment #24)
> Manuel, I'm at a conference and then travelling without regular access to test
> machines, but I hope to get to this early next week.
>
Thanks. No hurry, just to let you know. I will keep
--- Comment #2 from danglin at gcc dot gnu dot org 2007-03-02 00:53 ---
This is probably a duplicat of PR 29478.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30183
sable-libmudflap --enable-languages=c,c++,objc,obj-c++,fortran,ada,java
Thread model: posix
gcc version 4.3.0 20070301 (experimental)
--
Summary: cannot write in
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priori
--- Comment #1 from danglin at gcc dot gnu dot org 2007-03-02 01:49 ---
The directory doesn't exist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31020
--- Comment #2 from joseph at codesourcery dot com 2007-03-02 02:05 ---
Subject: Re: cannot write in
I believe that the way the real-* rules are used, they don't actually need
to copy include after all, just include-fixed, so the code for copying
include can be removed from them.
--- Comment #3 from jsm28 at gcc dot gnu dot org 2007-03-02 02:21 ---
I'm preparing a followup patch to the include-fixed changes and will include a
fix for this issue.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org
|dot org
--- Comment #1 from bje at gcc dot gnu dot org 2007-03-02 05:28 ---
Subject: Bug 30992
Author: bje
Date: Fri Mar 2 05:28:06 2007
New Revision: 122469
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122469
Log:
2007-03-02 Ben Elliston <[EMAIL PROTECTED]>
PR 30992
--- Comment #2 from bje at gcc dot gnu dot org 2007-03-02 05:29 ---
Thanks also for the report on the C99 library!
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from ubizjak at gmail dot com 2007-03-02 07:31 ---
IMO there is no need for a bugreport in this case as there is no failure, bad
code or similar problems. You could just post a patch to gcc-patches.
--
ubizjak at gmail dot com changed:
What|Removed
72 matches
Mail list logo
