Hi,
among the support facilities required by C++0x there is:
//
20.9.9.1 addressof [specialized.addressof]
template class T T* addressof(T r);
1 Returns: the actual address of the object or function referenced by r,
even in the presence of an
overloaded operator.
Throws:
Hello,
I wrote following code:
#include iostream
#include string
#include dirent.h
int main()
{
struct dirent **namelist;
int numberOfProcDirs;
numberOfProcDirs=scandir(/proc, namelist, 0, alphasort);
//std::string temp(std::string(namelist[0]-d_name)+std::string(fdsfds));
//std::string
... for reference, it would be something like this (in my recollections,
it was even uglier ;)
templatetypename _Tp
_Tp*
addressof(_Tp __v)
{
return reinterpret_cast_Tp*
(const_castchar(reinterpret_castconst volatile char(__v)));
}
I'm not sure...
Paolo.
On 05/20/2010 01:10 PM, Paolo Carlini wrote:
... for reference, it would be something like this (in my recollections,
it was even uglier ;)
templatetypename _Tp
_Tp*
addressof(_Tp __v)
{
return reinterpret_cast_Tp*
(const_castchar(reinterpret_castconst volatile
On 05/20/2010 01:10 PM, Paolo Carlini wrote:
... for reference, it would be something like this (in my recollections,
it was even uglier ;)
templatetypename _Tp
_Tp*
addressof(_Tp __v)
{
return reinterpret_cast_Tp*
(const_castchar(reinterpret_castconst volatile char(__v)));
}
Hi,
... for reference, it would be something like this (in my
recollections,
it was even uglier ;)
templatetypename _Tp
_Tp*
addressof(_Tp __v)
{
return reinterpret_cast_Tp*
(const_castchar(reinterpret_castconst volatile
char(__v)));
}
It's uglier because the code
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
Paolo.
On Mon, May 17, 2010 at 8:44 AM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
CodeSourcery is working on improving performance for Intel's Core 2 and Core
i7 families of processors.
CodeSourcery plans to add support for unaligned vector instructions, to
provide fine-tuned scheduling support
On 5/20/10 4:04 PM, Steven Bosscher wrote:
On Mon, May 17, 2010 at 8:44 AM, Maxim Kuvyrkovma...@codesourcery.com wrote:
CodeSourcery is working on improving performance for Intel's Core 2 and Core
i7 families of processors.
CodeSourcery plans to add support for unaligned vector instructions,
Paolo Carlini wrote:
On 05/20/2010 02:18 PM, Peter Dimov wrote:
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
This is
Sent from my iPhone
On May 20, 2010, at 5:43 AM, Peter Dimov pdi...@pdimov.com wrote:
Paolo Carlini wrote:
On 05/20/2010 02:18 PM, Peter Dimov wrote:
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a
I observed the following issue with g++-4.3.4:
I can work around the restriction of initializing a static const integral
class member with a non-constant expression.
This violates the standard and should be rejected by -pedantic.
Correct me, if I'm wrong.
I cut down my code to the following
Hello,
For some time now, I've wanted to see where compile time goes in a
typical GCC build, because nobody really seems to know what the
compiler spends its time on. The impressions that get published about
gcc usually indicate that there is at least a feeling that GCC is not
getting faster, and
Robert Grimm wrote:
Actually, I saw some old posts that talked about a -fno-implicit-fp option
[I know this is a very old post, but I noticed it in old email and felt
it might still be useful to reply.]
CodeSourcery has a -fno-implicit-fp option that does exactly what you
have requested in
On 05/20/2010 11:21 AM, Mark Mitchell wrote:
Robert Grimm wrote:
Actually, I saw some old posts that talked about a -fno-implicit-fp option
[I know this is a very old post, but I noticed it in old email and felt
it might still be useful to reply.]
CodeSourcery has a
Joel Sherrill wrote:
I know RTEMS users have asked about this option before.
We have the same problem since we also support floating
point as an optional task attribute. On some tasks we implicitly
make the port force all tasks to have FP contexts.
Why was this rejected and not merged?
On Sun, May 02, 2010 at 11:38:39PM +0200, Gerald Pfeifer wrote:
As http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00120.html shows,
*-unknown-freebsd* exhibits tons of failures around LTO.
I dug a bit deeper, and even the most trivial test program
int main() { }
fails with
lto1:
Yixuan Huang yixuan...@gmail.com writes:
I wrote following code:
#include iostream
#include string
#include dirent.h
int main()
{
struct dirent **namelist;
int numberOfProcDirs;
numberOfProcDirs=scandir(/proc, namelist, 0, alphasort);
//std::string
Jan Tusch tu...@isg.cs.uni-magdeburg.de writes:
I observed the following issue with g++-4.3.4:
I can work around the restriction of initializing a static const integral
class member with a non-constant expression.
This violates the standard and should be rejected by -pedantic.
Correct me,
On 05/20/2010 08:18 AM, Peter Dimov wrote:
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
This is probably a g++/gcc
On 05/20/2010 08:13 PM, Jason Merrill wrote:
The standard permits a compiler to accept or reject such a cast.
5.2.10/8: Converting a pointer to a function into a pointer to an
object type or vice versa is conditionally-supported. The meaning of
such a conversion is implementation-defined,
Jason Merrill wrote:
On 05/20/2010 08:18 AM, Peter Dimov wrote:
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
This is
Hello,
The Obj-C++ front end is effectively unmaintained, and has virtually
no serious users. I propose to remove it from GCC.
Perhaps the only user of some significance is GNUstep, but they are
already in an awkward position because they wish to use ObjC 2.0, and
they are looking at clang for
Steven Bosscher wrote:
Hello,
For some time now, I've wanted to see where compile time goes in a
typical GCC build, because nobody really seems to know what the
compiler spends its time on. The impressions that get published about
gcc usually indicate that there is at least a feeling that GCC
No Asbestos required - but .. I do have some observations..
I write pretty much all my serious (day-job) code in ObjC and..
... I have stated that it's an intention to make *that*, at least
work at V2 on FSF.
Having said that:
a) I have not anything like as much attachment to ObjC++ ...
On 05/20/2010 09:17 PM, Vladimir Makarov wrote:
Steven Bosscher wrote:
For some time now, I've wanted to see where compile time goes in a
typical GCC build, because nobody really seems to know what the
compiler spends its time on. The impressions that get published about
gcc usually indicate
On Thu, 2010-05-20 at 21:02 +0200, Steven Bosscher wrote:
Hello,
The Obj-C++ front end is effectively unmaintained, and has virtually
no serious users. I propose to remove it from GCC.
Maybe we could consider, for the putative people wanting to maintain
that frontend, to make it a plugin (or
On Thu, May 20, 2010 at 9:54 PM, IainS develo...@sandoe-acoustics.co.uk wrote:
No Asbestos required - but .. I do have some observations..
I write pretty much all my serious (day-job) code in ObjC and..
... I have stated that it's an intention to make *that*, at least work at
V2 on FSF.
On Thu, May 20, 2010 at 10:20 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Thu, 2010-05-20 at 21:02 +0200, Steven Bosscher wrote:
Hello,
The Obj-C++ front end is effectively unmaintained, and has virtually
no serious users. I propose to remove it from GCC.
Maybe we could
* Adding and subtracting the above numbers, the rest of the compiler,
which is mostly the RTL parts, still account for 100-17-16-8=59% of
the total compile time. This was the most surprising result for me.
That figure is a little skewed though, the rest is not entirely RTL.
Front-end (3):
Hi Vlad,
On Thu, May 20, 2010 at 9:17 PM, Vladimir Makarov wrote:
For some time now, I've wanted to see where compile time goes in a
typical GCC build, because nobody really seems to know what the
compiler spends its time on. The impressions that get published about
gcc usually indicate that
That figure is a little skewed though, the rest is not entirely RTL.
Now without some annoying typo in a formula...
Front-end (3):
lexical_analysis 6.65
preprocessing 27.59
parser 31.53
Hi,
I don't know is it big or not to have such time spend in RTL parts. But I
think that this RTL part could be decreased if RTL (magically :) would have
smaller footprint and contain less details.
checks pockets...
Bah, no wand... :-)
I noticed while working on the dragonegg plugin that
Steven Bosscher stevenb@gmail.com writes:
And finally: expand. This should be just a change of IR format, from
GIMPLE to RTL. I have no idea why this pass always shows up in the top
10 of slowest parts of GCC. Lowering passes on e.g. WHIRL, or GENERIC
lowering to GIMPLE, never show up in
On Thu, May 20, 2010 at 2:09 PM, Ian Lance Taylor i...@google.com wrote:
Steven Bosscher stevenb@gmail.com writes:
And finally: expand. This should be just a change of IR format, from
GIMPLE to RTL. I have no idea why this pass always shows up in the top
10 of slowest parts of GCC.
On Thu, May 20, 2010 at 10:54 PM, Duncan Sands baldr...@free.fr wrote:
I noticed while working on the dragonegg plugin that replacing gimple - RTL
with gimple - LLVM IR significantly reduced the amount of memory used by
the compiler at -O0. I didn't investigate where the memory was going, but
On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li davi...@google.com wrote:
stack variable overlay and stack slot assignments is here too.
Yes, and for these I would like to add a separate timevar. Agree?
Ciao!
Steven
On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher stevenb@gmail.com wrote:
On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li davi...@google.com
wrote:
stack variable overlay and stack slot assignments is here too.
Yes, and for these I would like to add a separate timevar. Agree?
Yes.
On my codes, pre-RA instruction scheduling on X86-64 (a) improves run
times by roughly 10%, and (b) costs a lot of compile time.
The -fscheduling option didn't seem to be on in your time tests (I think
it's not on by default on that architecture at -O2).
Brad
Hello,
I have a FORTRAN code that uses some c routines. I compile it with gcc
and gfortran in RedHat Linux without any problem. Recently I bought a
laptop with Ubuntu. I have gcc and gfortran version 4.4.3 in it. When
I compile the code, I see the following warning:
warning: ignoring return value
Hello,
I have a FORTRAN code that uses some c routines. I compile it with gcc
and gfortran in RedHat Linux without any problem. Recently I bought a
laptop with Ubuntu. I have gcc and gfortran version 4.4.3 in it. When
I compile the code, I see the following warning:
warning: ignoring return value
Snapshot gcc-4.5-20100520 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100520/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Muhammad Akbar mkak...@gmail.com writes:
I have a FORTRAN code that uses some c routines. I compile it with gcc
and gfortran in RedHat Linux without any problem. Recently I bought a
laptop with Ubuntu. I have gcc and gfortran version 4.4.3 in it. When
I compile the code, I see the following
On May 20, 2010, at 8:04 AM, Steven Bosscher wrote:
On Mon, May 17, 2010 at 8:44 AM, Maxim Kuvyrkov ma...@codesourcery.com
wrote:
CodeSourcery is working on improving performance for Intel's Core 2 and Core
i7 families of processors.
CodeSourcery plans to add support for unaligned vector
On Thu, May 20, 2010 at 09:40:47AM -0700, Mark Mitchell wrote:
It is of course a feature much
less valuable on a workstation/server class operating system than on the
VxWorks/RTEMS class of RTOS systems.
Even on servers this option may be quite valuable. I recall seing
figures that showed
On Thu, May 20, 2010 at 9:35 PM, Alan Modra amo...@gmail.com wrote:
On Thu, May 20, 2010 at 09:40:47AM -0700, Mark Mitchell wrote:
It is of course a feature much
less valuable on a workstation/server class operating system than on the
VxWorks/RTEMS class of RTOS systems.
Even on servers this
David Edelsohn wrote:
It is of course a feature much
less valuable on a workstation/server class operating system than on the
VxWorks/RTEMS class of RTOS systems.
No one disagrees with the potential benefit of the feature.
OK; I must have misremembered.
I believe our current implementation
The following valid code snippet triggers an ICE on trunk when compiled with
-O3 on i686-pc-linux-gnu and x86_64-unknown-linux-gnu:
===
templateint struct A
{
void foo(void(*)(A));
void bar(void(*f)(A)) { foo(f); foo(f); }
};
templateint N
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44206
--- Comment #12 from reichelt at gcc dot gnu dot org 2010-05-20 06:25
---
The failure in comment #1 might be related to PR 44206.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--- Comment #1 from wilson at gcc dot gnu dot org 2010-05-20 06:27 ---
Subject: Bug 43764
Author: wilson
Date: Thu May 20 06:26:52 2010
New Revision: 159610
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159610
Log:
PR target/43764
* mips.c (mips_call_expr_from_insn): New arg
--- Comment #2 from wilson at gcc dot gnu dot org 2010-05-20 06:27 ---
Mine.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from hp at gcc dot gnu dot org 2010-05-20 06:45 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:44:45 2010
New Revision: 159611
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159611
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #3 from hp at gcc dot gnu dot org 2010-05-20 06:46 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:45:38 2010
New Revision: 159612
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159612
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #4 from hp at gcc dot gnu dot org 2010-05-20 06:47 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:47:41 2010
New Revision: 159613
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159613
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #5 from hp at gcc dot gnu dot org 2010-05-20 06:48 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:48:37 2010
New Revision: 159614
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159614
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #6 from hp at gcc dot gnu dot org 2010-05-20 06:50 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:50:15 2010
New Revision: 159615
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159615
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #7 from hp at gcc dot gnu dot org 2010-05-20 06:51 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:51:05 2010
New Revision: 159616
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159616
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #8 from hp at gcc dot gnu dot org 2010-05-20 06:52 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:52:25 2010
New Revision: 159617
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159617
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #9 from hp at gcc dot gnu dot org 2010-05-20 06:53 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:53:34 2010
New Revision: 159618
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159618
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #10 from hp at gcc dot gnu dot org 2010-05-20 07:02 ---
Fixed, see also http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01456.html.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from irar at il dot ibm dot com 2010-05-20 07:13 ---
Do you mean that extract_even implementation does something illegal with this
last element? Misaligned load also accesses elements outside the array, but the
problem is in extract_even?
Other than doing something in
--- Comment #5 from burnus at gcc dot gnu dot org 2010-05-20 07:40 ---
TODO: Constraint checks are missing and partially incorrect,
cf. http://gcc.gnu.org/ml/fortran/2010-05/msg00225.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
program ice_prog
type::ice_type
integer,dimension(:),allocatable::list
end type ice_type
type(ice_type)::this
integer::dim,i
allocate(this%list(dim),source=[(i,i=1,dim)])
end program ice_prog
Compiling this with GNU Fortran (GCC) 4.6.0 20100518 (experimental) will cause
a segmentation
--- Comment #1 from borntraeger at de dot ibm dot com 2010-05-20 08:29
---
Indeed. I think I found a typo when handling array prefetches.
a potential fix might be:
--- gcc/tree-ssa-loop-prefetch.c(Revision 159557)
+++ gcc/tree-ssa-loop-prefetch.c(Arbeitskopie)
@@
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-20 08:50 ---
(In reply to comment #1)
Do you mean that extract_even implementation does something illegal with this
last element? Misaligned load also accesses elements outside the array, but
the
problem is in extract_even?
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-20 08:52 ---
Confirmed. Note that as such the code is invalid (dim is not set), but adding a
line dim=10 does not remove the ICE. The backtrace is:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason:
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-20 09:36 ---
Confirmed. The problem occurs with allocatable components only, allocatable
variables are fine.
#0 0x0813d1cd in conformable_arrays (e1=0x8bff710, e2=0x8bc9a30) at
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-20 09:57
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2010-05-20 10:04 ---
I am curious what is the problem with that? These elements are not used, they
are just loaded...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
--- Comment #4 from mikpe at it dot uu dot se 2010-05-20 10:18 ---
(In reply to comment #3)
I am curious what is the problem with that? These elements are not used, they
are just loaded...
An out-of-bounds read can result in a SEGV if the memory is unmapped. Worse
things can happen
--- Comment #26 from redi at gcc dot gnu dot org 2010-05-20 10:18 ---
I tweaked the patch to apply it to 4.4.3 (replacing ASM_BYTE with .byte) and it
fixes the bootstrap failure for this config:
--enable-languages=c,c++,fortran --with-arch=core2 --with-as=/usr/sfw/bin/gas
--with-gnu-as
--- Comment #5 from irar at il dot ibm dot com 2010-05-20 10:24 ---
Even if we are talking about less than vector size from array boundary? And
that boundary is not (vector) aligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-20 10:29 ---
Subject: Bug 44074
Author: jakub
Date: Thu May 20 10:28:36 2010
New Revision: 159622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159622
Log:
PR target/44074
* configure: Regenerate.
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-20 10:30 ---
Patching in configure pieces generated with autoconf 2.64 into autoconf 2.59
generated configure totally broke the branch, configure after a few errors kept
printing y in an endless loop.
--
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-20
10:32 ---
Subject: Re: Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on
same line
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-20 10:30
---
Patching in configure pieces
--- Comment #6 from mikpe at it dot uu dot se 2010-05-20 11:05 ---
It depends on the specific values of (a) array end alignment and (b) the number
of bytes read. As long as the array end + number of bytes read can cross a page
boundary, you're potentially causing SEGV or other errors.
--- Comment #1 from dodji at gcc dot gnu dot org 2010-05-20 11:06 ---
A patch has been proposed to
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01476.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
Sorry, I report this bug with a Major severity, because it applies to all
front-ends and backends.
Consider the following code:
static void f() __attribute__((warning(should not be linked)));
void f() {}
int main() { f(); }
---
You just can't compile it without removing -Werror,
because
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-20 11:40 ---
IMHO this is an enhancement request, not severity=Major
-Werror is not on by default, if you choose to enable it then you deal with the
consequences.
Obviously the ideal is for every warning to be controllable by an
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-20 11:45 ---
N.B. Bug 44054 is the PR for the fortran FE to support -Werror= etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
As I always wonder if my compiler could help me find more bugs,
and the list of warnings I enable tend to be very long,
and -Wall is not enough for me...
(This bug certainly depends on #44209: Some warnings are not linked to
diagnostics options)
It would be great to have the following options:
--- Comment #16 from rguenther at suse dot de 2010-05-20 11:48 ---
Subject: Re: [4.5 Regression] Aliasing bug triggered by
Boost.Bind/Boost.Function
On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:
--- Comment #15 from jason at gcc dot gnu dot org 2010-05-20 05:35
--- Comment #10 from ro at gcc dot gnu dot org 2010-05-20 12:06 ---
Subject: Bug 43870
Author: ro
Date: Thu May 20 12:05:54 2010
New Revision: 159625
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159625
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare):
--- Comment #11 from ro at gcc dot gnu dot org 2010-05-20 12:07 ---
Subject: Bug 43870
Author: ro
Date: Thu May 20 12:07:23 2010
New Revision: 159626
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159626
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare):
--- Comment #12 from ro at gcc dot gnu dot org 2010-05-20 12:08 ---
Subject: Bug 43870
Author: ro
Date: Thu May 20 12:08:34 2010
New Revision: 159627
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159627
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare):
--- Comment #13 from ro at gcc dot gnu dot org 2010-05-20 12:10 ---
Fixed for 4.4.5, 4.5.1, 4.6.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from segher at gcc dot gnu dot org 2010-05-20 12:10 ---
I don't see the problem with 4.3 .
Kyle, are you sure it doesn't happen for you with 4.4?
I use
powerpc-linux-gnuspe-gcc -Wall -W -O1 -pthread -ftls-model=initial-exec
-mcpu=8540 -fPIC -S t.c -fverbose-asm
paste
--- Comment #7 from joakim dot tjernlund at transmode dot se 2010-05-20
12:13 ---
The below code doesn't generate any add with carry insn's for
either x86 nor powerpc:
u16
ipsum(u16 *buf, unsigned len, u16 sum)
{
int rest, carry ;
u32 acc_sum, *buf_u32, x;
acc_sum = sum;
len
--- Comment #7 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:17 ---
Created an attachment (id=20707)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20707action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.3.4
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44204
module ice_module
type::ice_type
class(ice_type),pointer::next
contains
procedure::ice_proc
end type ice_type
contains
subroutine ice_proc(this)
class(ice_type)::this
end subroutine ice_proc
subroutine ice_sub()
type(ice_type),dimension(2)::ice_array
--- Comment #8 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:19 ---
Created an attachment (id=20708)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20708action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.4
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44203
--- Comment #2 from borntraeger at de dot ibm dot com 2010-05-20 12:28
---
Created an attachment (id=20709)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20709action=view)
new version of the fix.
There is actually a second bug :-(
We not only have to replace step with stepsize
--- Comment #9 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:29 ---
Created an attachment (id=20710)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20710action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.2
--
--- Comment #10 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:37 ---
Ok, it looks like the bug was introduced in the 4.4 branch between 4.4.2 and
4.4.4, because my old GCC 4.4.2 compiler works, but the 4.4.4 I built yesterday
after I noticed this report does not.
If
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-05-20 13:24
---
It is actually the scheduler that breaks the testcase. Easier to look at
is -O2 -fwhole-program. -fno-schedule-insns2 fixes it (as well as
-fno-tree-pre
or -fno-tree-dominator-opts, both of which are necessary
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-20 13:27 ---
So, we have:
bb 3:
[pr44205.c : 7:11] i.1_2 = i;
[pr44205.c : 7:10] if (i.1_2 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
[pr44205.c : 8:4] i = 0;
goto bb 6;
bb 5:
[pr44205.c : 10:4] i = 1;
bb 6:
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-20 13:31 ---
(In reply to comment #0)
This would allow reducing this (infamous) list:
-W -Wall -Wextra -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wconversion
-Winline -Wmissing-field-initializers -Wshadow -Wcast-align -Wformat=2
1 - 100 of 194 matches
Mail list logo
