Denys Vlasenko wrote:
I tend to doubt that odd-byte aligned large memcpys are anywhere
near typical. malloc and mmap both return well-aligned buffers
(say, 8 byte aligned). Static and on-stack objects are also
at least word-aligned 99% of the time.
memcpy can just use relatively simple code for
Hello All,
Some middle-end passes (those declared in tree-passes.h) are still unnamed.
I tend to believe that it would be helpful (mostly for gcc debugging
purposes) that every struct opt_pass (without exception) should be
uniquely named (and that this should be enforced, eg. in
Sent from my iPhone
On Jul 31, 2008, at 1:11, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
Hello All,
Some middle-end passes (those declared in tree-passes.h) are still
unnamed.
I tend to believe that it would be helpful (mostly for gcc debugging
purposes) that every struct
Andrew Thomas Pinski wrote:
Sent from my iPhone
Except as a habit (which I think is a bad one) is there any reason to
have anonymous passes (those with a null pass-name), or (I don't know
if such beast exists) homonym passes (two different passes with equal
pass-name)?
Yes. To prevent a
Hi,
When I encounter a FUNCTION_DECL, I want to access the node BIND_EXPR
where I can find the artificial declarations of the current functions
that the compiler adds. Following what the documentation says, I use the
macro DECL_SAVED_TREE which should point to the node BIND_EXPR (used as
Basile STARYNKEVITCH wrote:
Andrew Thomas Pinski wrote:
Except as a habit (which I think is a bad one) is there any reason to
have anonymous passes (those with a null pass-name), or (I don't
know if such beast exists) homonym passes (two different passes with
equal pass-name)?
Yes. To
Status
==
The GCC 4.3 branch is open for commits under normal release branch
rules. The 4.3.2 release was expected around 2008-08-06, but as
there are still P1s, it might be delayed a little bit.
Quality Data
Priority # Change from Last Report
---
Agner Fog wrote on 31 July 2008 07:14:
Denys Vlasenko wrote:
I tend to doubt that odd-byte aligned large memcpys are anywhere
near typical. malloc and mmap both return well-aligned buffers
(say, 8 byte aligned). Static and on-stack objects are also
at least word-aligned 99% of the time.
On Thu, Jul 31, 2008 at 12:48 AM, Brian Dessent [EMAIL PROTECTED] wrote:
Benjamin Smedberg wrote:
For what it's worth, Bo is my intern in the Google SoC and has traced this
back to being a code-generation error (missed stdcall mangling) in the mingw
backend. I will work with him to narrow the
Andrew, Can you explain more why?
Why I'm asking again now:
I have found another problem because of this (besides the
reduced ability to share config.cache files).
This exacerbates what looks like a minor bug in gmp's configure.
Sometimes, depending on build/host/target, gmp's configure
sets
Paolo Carlini wrote:
Hi ho, ho!! ;)
It worked with me.
Try a recent gcc (eg, 4.3.x) and you will get the same, actually
expected, result of the original poster.
Paolo.
I believe this is a bug. I agree that -ffast-math will not always comply 100%
with IEEE, as advertised. But, if I
Neal Becker wrote on 31 July 2008 12:42:
Paolo Carlini wrote:
Hi ho, ho!! ;)
It worked with me.
Try a recent gcc (eg, 4.3.x) and you will get the same, actually
expected, result of the original poster.
Paolo.
I believe this is a bug. I agree that -ffast-math will not always comply
Dave Korn wrote on 31 July 2008 12:45:
Neal Becker wrote on 31 July 2008 12:42:
If it is really intended not to work, then at least
documentation should state that.
It does, as was already explained to you; re-read the thread.
Actually I can be more use than that, I'll show you the
Priority # Change from Last Report
--- ---
P13 - 5
P2 115 - 2
P32 - 1
--- ---
Total 120 - 8
PR35752, which is a P2 regression
As we are approaching the intended release date of 4.3.2 we need to
address the P1 bugs or downgrade them accordingly. Two of the P1s
have patches posted (more than 3 resp. 2 weeks ago), so they just
need reviewing.
For the record, these are:
Hi Paolo,
* Paolo Bonzini wrote on Thu, Jul 31, 2008 at 02:53:21PM CEST:
PR35752, which is a P2 regression caused by libtool, is waiting for
approval upstream. Should we make an exception to the usual rules and
apply the fix on the branch?
If by exception to the usual rule, you mean
Ralf Wildenhues wrote:
Hi Paolo,
* Paolo Bonzini wrote on Thu, Jul 31, 2008 at 02:53:21PM CEST:
PR35752, which is a P2 regression caused by libtool, is waiting for
approval upstream. Should we make an exception to the usual rules and
apply the fix on the branch?
If by exception to the
On Thu, Jul 31, 2008 at 03:10:46PM +0200, Paolo Bonzini wrote:
Ralf Wildenhues wrote:
Tomorrow it's a public holiday here, so I wouldn't apply the patch
before monday anyway.
If the patch is checked in on Monday or Tuesday, that's still fine,
no need to use exceptions.
Jakub
Jay wrote:
Andrew, Can you explain more why?
Because at some point, no released version worked on intel macs.
And then gmp/configure runs flex.
And then sometimes?always flex tries to run getenv(M4) || m4.
Yes, Flex uses m4.
gmp/configure probably should not be setting M4
Yes, I think
Paolo Bonzini wrote:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01305.html
dwarf2out.c (CCing Jason Merrill)
That patch went in a while back, but your message led me to the one that
still needed reviewing. :)
Jason
Bo Yang wrote:
When we produce an exe from a single c++ file, there is no linking
need, so there is no problem. But when we separate the definition and
That's not how it works, the linker is always required to produce an
executable.
And Obviously, this is not a linker error, it is the
Arnaud Charlet wrote:
For half a year now, I've been working on the GCC Fortran front-end; but
I'm also quite interested in Ada as a language. However, I don't quite
like the idea that one needs a working Ada compiler to bootstrap the Ada
front-end. Well, it's the same with a C compiler to
Well, the point is, I'm using a GNU/Linux system I mainly built from
scratch, so there's no easy package-installer available for me and I've to
built everything from source (which is, of course, my own fault). My
system started out with a gcc C compiler, so I could easily bootstrap and
On Thu, 2008-07-31 at 18:42 +0200, Daniel Kraft wrote:
With Ada, however, I'm at least not aware of another compiler I could
bootstrap using my C compiler and use that one subsequentally to
bootstrap GNAT. At the moment, I'm trying to bootstrap it using a
binary GNAT 3.15p which was also
Hi,
I seem to have bumped into something. I threw away
my svn trunk checkout and did another just in case.
There are no Ada multilib patches in this tree.
I have checked and am pretty sure I have no changes
to anything that is not an RTEMS run-time related file.
I can build a native compiler
Hello,
i had the following Problem today:
I have a class called GUI, that i included and instantiated.
Today i extended my Code (among other things) with an enum that had an
Element 'GUI'.
I didn't knew that this isn't possible and never even thought about it.
When i tried to compile my Code, i
Dear All,
We continue developing adaptable GCC (MILEPOST GCC) and we plan to have more
results this fall on selecting good optimization passes and their orders
to improve program execution time, reduce code size and compilation time
across different architectures automatically using statistical
ingmar wirths [EMAIL PROTECTED] writes:
I hope you don't consider this as flaming or something, just critics
to improve this wonderful compiler
and make hacking easier for people like me without an expert
understanding of C++.
Thanks for your note. Unfortunately it is too vague for us to
Grigori,
Many of the costs now are handled by GCC parameters. See
gcc/params.def accessed in the source code using PARAM_VALUE.
Many other cost models use macros with COST in their name, such as
TARGET_RTX_COSTS / rtx_cost
BRANCH_COST (and LOGICAL_OP_NON_SHORT_CIRCUIT)
Snapshot gcc-4.3-20080731 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080731/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Quite a few files in libiberty use XNEWVEC as a replacement for
malloc(), but the they are being paired with plain free(); XDELVEC is
not being used.
Is there some reason for the inconsistency, such as some transitional
issue, or should this be fixed?
Is there some reason for the inconsistency,
Not really. Patches welcome.
Thanks, David!
That's a good start. I will need to find places in GCC where these
parameters are used to monitor the behavior of transformations
based on these parameters and be able to change the compiler decisions
through ICI to learn how to tune those costs based on program execution
On Thursday 31 July 2008 11:36, Dave Korn wrote:
Agner Fog wrote on 31 July 2008 07:14:
Denys Vlasenko wrote:
I tend to doubt that odd-byte aligned large memcpys are anywhere
near typical. malloc and mmap both return well-aligned buffers
(say, 8 byte aligned). Static and on-stack
On Thu, Jul 31, 2008 at 11:00 PM, Brian Dessent [EMAIL PROTECTED] wrote:
Bo Yang wrote:
When we produce an exe from a single c++ file, there is no linking
need, so there is no problem. But when we separate the definition and
That's not how it works, the linker is always required to produce
The comments in passes.c at the beginning are identical to toplev.c.
--
此致
敬礼！
梁��
This doesn't work: g++-4.3.1
These work: g++-3.4.6 g++-4.1.2 g++-4.2.4
$ g++-4.3.1 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1
At revision 138355 the compiler configured with RTL checking fails to bootstrap
on i586-suse-linux with:
/home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/
-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-07-31 06:57
---
Created an attachment (id=15980)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15980action=view)
Preprocessed file to be compiled with -msse -g -mtune=i586.
--
--- Comment #1 from fang at csl dot cornell dot edu 2008-07-31 07:00
---
See PR 25950 and all of its dupes.
The copy constructor needs to be publicly accessible where the temporary rvalue
is bound to a reference parameter.
--
fang at csl dot cornell dot edu changed:
--- Comment #30 from pinskia at gcc dot gnu dot org 2008-07-31 07:03
---
*** Bug 36490 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-31 07:03 ---
*** This bug has been marked as a duplicate of 25950 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-31 07:08 ---
Yes this code is definitely wrong as on the PPC, we can load the stack pointer
from memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
Template nested inner classes are not resolved:
template typename T
class A
{
public:
class AA { };
};
template typename T
class B : public AT
{
public:
class BB : public AA { };
//class BB : public AT::AA { }; // Workaround.
};
int main(int argc, char* argv[])
{
Bint b;
return 0;
}
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-07-31 07:16
---
Just to confirm that reverting r138135-r138140 makes the bug vanish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
--- Comment #1 from 4ekucT at tut dot by 2008-07-31 07:17 ---
Created an attachment (id=15981)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15981action=view)
Template nested inner classes are not resolved.
Compile to reproduce the bug.
--
--- Comment #1 from fang at csl dot cornell dot edu 2008-07-31 07:19
---
Dupe of PR 30734 (first reported as PR 2708).
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #21 from aldot at gcc dot gnu dot org 2008-07-31 07:56 ---
Lothar, see #10
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--- Comment #4 from jakub at gcc dot gnu dot org 2008-07-31 08:00 ---
Subject: Bug 36649
Author: jakub
Date: Thu Jul 31 07:59:18 2008
New Revision: 138360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138360
Log:
PR preprocessor/36649
* c-pch.c
--- Comment #3 from jakub at gcc dot gnu dot org 2008-07-31 08:02 ---
Subject: Bug 36278
Author: jakub
Date: Thu Jul 31 08:01:25 2008
New Revision: 138361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138361
Log:
PR debug/36278
* dwarf2out.c (get_context_die):
--- Comment #1 from jakub at gcc dot gnu dot org 2008-07-31 08:04 ---
Subject: Bug 36970
Author: jakub
Date: Thu Jul 31 08:02:49 2008
New Revision: 138362
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138362
Log:
PR c/36970
* builtins.c (maybe_emit_free_warning):
// The following self-contained code (see below, I dont know how to
// attach files to this report) produces the bug (see embedded comments).
//
// The command compiler command line and output is as this:
//
// g++ -c -O2 -I . -DSTATIC_BUILD -Wall x.cpp
// x.cpp: In function bool
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-31 08:34
---
This is standard conforming behavior.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-31 08:39
---
*** This bug has been marked as a duplicate of 30734 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-31 08:39
---
*** Bug 36709 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2008-07-31 08:45 ---
Subject: Bug 36649
Author: jakub
Date: Thu Jul 31 08:44:24 2008
New Revision: 138368
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138368
Log:
PR preprocessor/36649
* c-pch.c
--- Comment #4 from jakub at gcc dot gnu dot org 2008-07-31 08:49 ---
Subject: Bug 36278
Author: jakub
Date: Thu Jul 31 08:48:26 2008
New Revision: 138369
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138369
Log:
PR debug/36278
* dwarf2out.c (get_context_die):
--- Comment #6 from jakub at gcc dot gnu dot org 2008-07-31 08:51 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2008-07-31 08:51 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-31 08:52 ---
Implemented on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2008-07-31 08:59
---
Hi again. I have essentially only one substantive comment: can you double check
the implementation is correct vs 20.7.12.2.1/37 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
$ cat mgrid.f
SUBROUTINE RESID(U,V,R,N,A)
INTEGER N
REAL*8 U(N,N,N),V(N,N,N),R(N,N,N),A(0:3)
INTEGER I3, I2, I1
DO 600 I3=2,N-1
DO 600 I2=2,N-1
DO 600 I1=2,N-1
600 R(I1,I2,I3)=V(I1,I2,I3)
-A(0)*( U(I1, I2, I3 ) )
-A(1)*(
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-31 09:19 ---
Works for me. Very likely a dup of PR36967.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2008-07-31 09:25 ---
Downgrading to P2, as the required changes are probably too big and risky for
the branches.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
lapack-lite-3.1.1/TESTING/LIN/schkeq.f
gfortran -c schkeq.f -O3 -msse2 -mfpmath=sse -funroll-loops -fbounds-check
schkeq.f: In function 'schkeq':
schkeq.f:445: internal compiler error: in df_ref_chain_change_bb, at
df-scan.c:1828
Please submit a full bug report,
with preprocessed source if
--- Comment #1 from domob at gcc dot gnu dot org 2008-07-31 10:31 ---
So the following two lines should give this error, right:
subroutine test (a)
character(len(a)) :: a
end subroutine test
subroutine test2 (n, arr)
integer :: arr(n), n
end subroutine test2
where in test2,
GCC:
% /usr/local/gcc-4.3.1/bin/g++-4.3.1 -v
Using built-in specs.
Target: i386-apple-darwin9.3.0
Configured with: ../gcc-4.3.1/configure --disable-nls --enable-languages=c,c++
--program-suffix=-4.3.1 --prefix=/usr/local/gcc-4.3.1
Thread model: posix
gcc
--- Comment #1 from alexandre dot hamez at gmail dot com 2008-07-31 10:41
---
I don't how to attach the preprocessed source. The file weight more than 1000k
so it is refused by bugzilla. And I think that copy-paste 56000 lines of code
is not the right thing to do?
At least, it seams
--- Comment #2 from Joey dot ye at intel dot com 2008-07-31 10:50 ---
Yes. Just notice that latest trunk passes.
--
Joey dot ye at intel dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-31 11:03
---
By the way, I'm under the impression that the differences between the TR1 and
the C++0x versions are by now too many, way too many macros. At some point we
should byte the bullet and separate completely for a
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-31 11:14 ---
subroutine test2 (n, arr)
integer :: arr(n), n
end subroutine test2
That example is valid as n is then implicitly typed as integer, which is
later confirmed. It only becomes invalid using:
implicit none
or
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-31 11:24 ---
1000k compressed? If not, compress it. Otherwise put it on the web somewhere
and post the link. We really need it to do anything about it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
This bug is also caused by 138207, and latest trunk still fails (138353)
$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --disable-bootstrap
--enable-languages=c,c++,fortran --enable-checking=assert
Thread model: posix
gcc version 4.4.0 20080731
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-31 11:33 ---
There is an easy workaround. Just do not fold the re-generated condition.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from Joey dot ye at intel dot com 2008-07-31 11:33 ---
Created an attachment (id=15982)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15982action=view)
Preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36986
--- Comment #3 from alexandre dot hamez at gmail dot com 2008-07-31 11:33
---
Created an attachment (id=15983)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15983action=view)
Preprocessed sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-31 11:35 ---
Note it is not miscompiled, but instead the compiler crashes.
*** This bug has been marked as a duplicate of 36978 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-31 11:35 ---
*** Bug 36986 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from krebbel at gcc dot gnu dot org 2008-07-31 11:36 ---
Fixed.
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from tkoenig at gcc dot gnu dot org 2008-07-31 11:38
---
Is this still an issue after the tuples merge?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
--- Comment #3 from domob at gcc dot gnu dot org 2008-07-31 11:54 ---
Thanks for the quick reply, Tobias. I'll try to get the used but not yet
typed part implemented to emit errors for -std != gnu.
To fix the problem in this PR, I see those possible solutions:
a) Disallow
--- Comment #2 from dodji at gcc dot gnu dot org 2008-07-31 12:22 ---
Created an attachment (id=15984)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15984action=view)
candidate partial fix
This patch fixes the problem patially.
if you have:
void
foo ()
{
#define
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
An initializer for a C struct with a variable sized last component is accepted,
but the data generated excludes the variable sized component.
struct s {
int16_t a,b,c,d;
int16_t y[];
} data = {0,0,0,0, {2,3,4,5}};
results in only the leading four int16_t values in the data segment.
Either
--- Comment #59 from bonzini at gnu dot org 2008-07-31 12:44 ---
Should be fixed by the patch at
http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/8574
which is waiting to be applied upstream.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #1 from howard dot thomson at dial dot pipex dot com
2008-07-31 12:50 ---
Created an attachment (id=15985)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15985action=view)
test for unexpected C struct field alteration
Due to the variable sized component of the struct
--- Comment #9 from bonzini at gnu dot org 2008-07-31 12:58 ---
Michael, any news?
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
/configure --enable-languages=c
--disable-bootstrap --enable-checking=all --prefix=/usr/gcc-4.4-work
--with-local-prefix=/usr/local
Thread model: posix
gcc version 4.4.0 20080731 (experimental) [trunk revision 138402] (GCC)
COLLECT_GCC_OPTIONS='-B../' '-m32' '-mtune=i586' '-g' '-v' '-S'
../cc1
--- Comment #1 from jason at gcc dot gnu dot org 2008-07-31 13:16 ---
*** This bug has been marked as a duplicate of 11309 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jason at gcc dot gnu dot org 2008-07-31 13:16 ---
*** Bug 36394 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2008-07-31 13:49 ---
This got actually fixed by Alan's PR target/36634 fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-31 13:50 ---
The analysis and a patch are posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02441.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-31 14:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-31 14:13 ---
Subject: Bug 36978
Author: rguenth
Date: Thu Jul 31 14:12:24 2008
New Revision: 138415
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138415
Log:
2008-07-31 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #1 from hjl at gcc dot gnu dot org 2008-07-31 14:35 ---
Subject: Bug 36976
Author: hjl
Date: Thu Jul 31 14:33:43 2008
New Revision: 138416
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138416
Log:
2008-07-31 H.J. Lu [EMAIL PROTECTED]
PR debug/36976
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-07-31 14:44 ---
Richard, there is one problem that is yours. We conclude that call is
uninlinable due to type missmatch. This should not happen on C++.
This gets misdiagnozed as originally recursive inlning was only reason why
typedef unsigned short __u16;
typedef unsigned int __u32;
typedef __u8 uint8_t;
typedef __u16 uint16_t;
typedef __u32 uint32_t;
typedef struct {
uint8_t mbxCommand;
} MAILBOX_t;
typedef struct lpfcMboxq {
};
int lpfc_sli_brdrestart(struct lpfc_hba * phba)
{
MAILBOX_t *mb;
uint16_t
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-31 14:51 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
With the code below, gcc complains over line 8, but not lines 14 and 17
because it deduces the wrong type for the ?: operator. The type of that
operator's result is dependent on whether something is a null pointer
constant and not. gcc fails to track that properly: it knows that
(const void *)0
1 - 100 of 135 matches
Mail list logo
