Hello,
I wonder why this order (non-consecutive, decreasing) of Altivec registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.
(taken from rs6000.h)
/* AltiVec registers. */\
77, 78,
Revital Eres wrote on 01/03/2007 10:37:36:
Hello,
I wonder why this order (non-consecutive, decreasing) of Altivec
registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.
(taken from rs6000.h)
/* AltiVec registers. */\
Hello:
I am Jiang Hongjiang and recently I am porting the GCC backend
to a DSP, and get puzzled about the decrement_and_branch_until_zero
pattern.By Reading the GCC source, I find that this pattern is used in
loop optimization, and it's used under the condition of defining the
doloop_end
Hi,
I noticed while editing gcc files, that there are a lot of *useless*
whitespaces at the end of lines or within empty lines, which are getting
automatic removed by some *smarter* editors as I am common to use *sigh*.
This leads to huge diff files and the real change is getting veiled. I
Kai Tietz wrote:
Hi,
I noticed while editing gcc files, that there are a lot of *useless*
whitespaces at the end of lines or within empty lines, which are getting
automatic removed by some *smarter* editors as I am common to use *sigh*.
This leads to huge diff files and the real change is
I noticed while editing gcc files, that there are a lot of *useless*
whitespaces at the end of lines or within empty lines, which are getting
automatic removed by some *smarter* editors as I am common to use *sigh*.
This leads to huge diff files and the real change is getting veiled. I
It also forbids embedded horizontal tabs for similar reasons (avoiding
junk difs).
That would be a problem with GCC, due to emacs being so heavily used,
but a similar convention *requiring* horizontal tabs would solve the
issue in question.
Thanks, that is what I want to hear. May it would be good point to run
over the source to be as the GNAT standard demands ?
Regards,
i.A. Kai Tietz
On 2/28/07, Diego Novillo [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote on 02/28/07 11:07:
Is there a way to install a finalizing function? (to be called after
all functions in the pass have been processed)
Or to know if the current function being processed is the last one?
(maybe if I know
Paulo J. Matos wrote on 03/01/07 10:41:
My IPA pass seems to be run only for -On, n=1, is there a way to make
it ran even for -O0?
No, we only run IPA passes if flag_unit_at_a_time is set. That only is
set when optimizing. At -O0, we simply emit functions individually.
On 3/1/07, Diego Novillo [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote on 03/01/07 10:41:
My IPA pass seems to be run only for -On, n=1, is there a way to make
it ran even for -O0?
No, we only run IPA passes if flag_unit_at_a_time is set. That only is
set when optimizing. At -O0, we simply
[EMAIL PROTECTED] (Richard Kenner) writes:
It also forbids embedded horizontal tabs for similar reasons (avoiding
junk difs).
That would be a problem with GCC, due to emacs being so heavily used,
but a similar convention *requiring* horizontal tabs would solve the
issue in question.
Emacs
redriver jiang [EMAIL PROTECTED] writes:
I am Jiang Hongjiang and recently I am porting the GCC backend
to a DSP, and get puzzled about the decrement_and_branch_until_zero
pattern.By Reading the GCC source, I find that this pattern is used in
loop optimization, and it's used under the
Sergei Organov wrote:
Emacs could be configured either way:
(setq-default indent-tabs-mode nil)
If that is to become a policy, simply append:
// Local Variables:
// whitespace-global-mode
// indent-tabs-mode:t
// tab-width:8
// c-basic-offset:4
// End:
At the end of each file. This way,
On Mar 1, 2007, at 12:57 AM, Tehila Meyzels wrote:
Revital Eres wrote on 01/03/2007 10:37:36:
Hello,
I wonder why this order (non-consecutive, decreasing) of Altivec
registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.
(taken from rs6000.h)
/* AltiVec
Successful build/install of gcc-4.1.2 on Solaris10
The previous version of GCC used for the build was 3.4.6
I just built the compiler until I worked around the toolchain
problems: downrev gawk and missing gmp (watch 32 vs 64 bit) and mpfr.
Then a reconfig for everything built and installed in
more potential conflicts between the trunk and the branch and makes
^^ branches
On 3/1/07, Mike Stump [EMAIL PROTECTED] wrote:
To steal an idea from llvm, if we permit post checkin review for
people that submit 100 good patches, would the wheels fall off the
bus? It seems to work for them, is there some reason why it couldn't
for us? Would it be more efficient and led to
On Mar 1, 2007, at 3:28 PM, Andrew Pinski wrote:
Also I think GCC is doing the correct thing right now with respect of
approving patches. Yes in the past we were not as good but now we
have corrected those mistakes.
So, are you saying that an 18 month review process isn't a mistake,
or that
On 3/1/07, Mike Stump [EMAIL PROTECTED] wrote:
On Mar 1, 2007, at 3:28 PM, Andrew Pinski wrote:
Also I think GCC is doing the correct thing right now with respect of
approving patches. Yes in the past we were not as good but now we
have corrected those mistakes.
So, are you saying that an
On Mar 1, 2007, at 4:51 PM, Andrew Pinski wrote:
No I am not saying that. I am saying that those patches might not
be worth commenting on.
Or, maybe they are. I think it would be better to have a policy that
addresses this issue, rather than require 18 months of silence for
someone to
On 3/1/07, Mike Stump [EMAIL PROTECTED] wrote:
I don't see why:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
was a bad thing. i think gcc would have been better if it had just
been committed.
(or the target removed)
It is not, just nobody cares about that target any more, we have
Mike Stump [EMAIL PROTECTED] writes:
I don't see why:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
was a bad thing. i think gcc would have been better if it had just
been committed.
Not fair. Zack himself says the patch is not recommended for commit,
and it just a
On Thu, 1 Mar 2007, Andrew Pinski wrote:
No I am not saying that. I am saying that those patches might not be
worth commenting on. If you feel they are worth commenting on, then
comment on them but I don't see you commenting on those patches at
all. I have not seen any patches that require
On 02/03/07, Andrew Pinski [EMAIL PROTECTED] wrote:
A week is too short of time to ping a patch.
Ups! I actually believed that a week was the recommended time to ping
a patch. What is it then?
And sorry for the ping-flood then.
Manuel.
On Fri, Mar 02, 2007 at 01:31:12AM +, Manuel López-Ibáñez wrote:
On 02/03/07, Andrew Pinski [EMAIL PROTECTED] wrote:
A week is too short of time to ping a patch.
Ups! I actually believed that a week was the recommended time to ping
a patch. What is it then?
Sometimes the only
On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
If someone wants a patch committed they will ping it
a couple of times and if they lost interest because they now decide it
is not a good thing or they no longer care about it, it will just fall
down the way side.
If it's a new
Mike Stump [EMAIL PROTECTED] writes:
Likewise:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html
This patch looks wrong to me. I don't understand how it could be
correct in the presence of __attribute__ ((aligned (N))). It checks
TYPE_PACKED but not TYPE_ALIGN or TYPE_USER_ALIGN.
On 02/03/07, Joe Buck [EMAIL PROTECTED] wrote:
On Fri, Mar 02, 2007 at 01:31:12AM +, Manuel López-Ibáñez wrote:
On 02/03/07, Andrew Pinski [EMAIL PROTECTED] wrote:
A week is too short of time to ping a patch.
Ups! I actually believed that a week was the recommended time to ping
a
On Fri, Mar 02, 2007 at 01:45:21AM +, Manuel López-Ibáñez wrote:
On 02/03/07, Joe Buck [EMAIL PROTECTED] wrote:
On Fri, Mar 02, 2007 at 01:31:12AM +, Manuel López-Ibáñez wrote:
On 02/03/07, Andrew Pinski [EMAIL PROTECTED] wrote:
A week is too short of time to ping a patch.
Olivier Galibert [EMAIL PROTECTED] writes:
On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
If someone wants a patch committed they will ping it
a couple of times and if they lost interest because they now decide it
is not a good thing or they no longer care about it, it will
Hi Ian,
I don't see why:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
was a bad thing. i think gcc would have been better if it had just
been committed.
Not fair. Zack himself says the patch is not recommended for commit,
and it just a baseline for further work. For this
Kazu Hirata [EMAIL PROTECTED] writes:
Hi Ian,
I don't see why:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
was a bad thing. i think gcc would have been better if it had just
been committed.
Not fair. Zack himself says the patch is not recommended for commit,
On 01 Mar 2007 18:05:50 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Olivier Galibert [EMAIL PROTECTED] writes:
On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
If someone wants a patch committed they will ping it
a couple of times and if they lost interest because they
On Thu, Mar 01, 2007 at 06:05:50PM -0800, Ian Lance Taylor wrote:
One answer to that is to have patch advocates to help push patches in.
They would need some experience with the community, but would not need
deep technical knowledge. This would be a volunteer position, along
the lines of the
Andrew Pinski wrote:
100 good patches != good knowledge in one area.
Also I think I already submitted 100 good patches but every once in a
while I submit a bad one though I think it is good to begin with.
To tangent off this in a rather different direction: One of the things
that I've noticed
--- 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=13129action=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
--- 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:
--- 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=gccview=revrev=122423
Log:
2007-03-01 Tobias Burnus [EMAIL PROTECTED]
PR
--
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=gccview=revrev=122424
Log:
2007-03-01 Paolo Carlini [EMAIL PROTECTED]
PR
--- 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=gccview=revrev=122427
Log:
fortran/
2007-03-01 Paul Thomas [EMAIL PROTECTED]
--- 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=gccview=revrev=122427
Log:
fortran/
2007-03-01 Paul Thomas [EMAIL PROTECTED]
--- 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
--- 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 stdio.h
#include stdint.h
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
--- 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 =
--- 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
--- 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,
--- 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,
--- 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|Removed
--- 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
--- 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=gccview=revrev=122430
Log:
PR other/16513
* Makefile.in: Install
--- 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=gccview=revrev=122431
Log:
fortran/
Backport from trunk
PR fortran/29441
* intrinsic.c
--- 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
--- 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=gccview=revrev=122433
Log:
fortran/
Backport from trunk
PR fortran/29441
* intrinsic.c
--- 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
--- 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
--- 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), it
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:
--
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
--- 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=13130action=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
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) =
--- 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=gccview=revrev=122434
Log:
cp/:
PR c++/23689
* decl.c (check_tag_decl): Added new
--- 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++)
--- 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
--- 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
--- 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
--- 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
--- 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 equal
--- 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
--- 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
--
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:
--- 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 */
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 simple
--- 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. In
--- 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
--- 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
1 - 100 of 108 matches
Mail list logo
