Q1) How to bootstrap the compiler, including all libraries?
A1) "make" from the top directory
Could some of the build system experts please provide the answers
for the following questions?
Q2) How to bootstrap the compiler, but not build any time consuming
libraries (libjava, libstdc++)?
On 1/15/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 1/15/07, pranav bhandarkar <[EMAIL PROTECTED]> wrote:
> Hello Everyone,
> I have the following source code
>
> static int i;
> static char a;
>
> char foo_gen(int);
> void foo_assert(char);
> void foo ()
> {
>int *x = &i;
>a = foo
On Mon, Jan 15, 2007 at 10:34:23PM +0200, Michael Veksler wrote:
> Roberto Bagnara wrote:
> >
> >Reading the thread "Autoconf manual's coverage of signed integer
> >overflow & portability" I was horrified to discover about GCC's
> >miscompilation of the remainder expression that causes INT_MIN % -1
On Mon, Jan 15, 2007 at 08:33:28PM -0800, H. J. Lu wrote:
> > > TARGET_ASM_EXTERNAL_LIBCALL when there is ASM_OUTPUT_EXTERNAL?
> >
> > In the larger scheme of things, we don't.
> >
> I will open a bug report for enhancement.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30480
H.J.
On Mon, Jan 15, 2007 at 08:23:05PM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > > Look at, e.g., mcore_external_libcall in mcore.c, and at
> > > ASM_OUTPUT_EXTERNAL_LIBCALL in i386/cygming.h. You need to handle
> > > cases like those somehow. I agree that we coul
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> > Look at, e.g., mcore_external_libcall in mcore.c, and at
> > ASM_OUTPUT_EXTERNAL_LIBCALL in i386/cygming.h. You need to handle
> > cases like those somehow. I agree that we could rework the way that
> > TARGET_ASM_EXTERNAL_LIBCALL works today, but no ma
On Mon, Jan 15, 2007 at 07:35:22PM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > process_pending_assemble_externals will be called at the end,
> > which calls assemble_external_real on all external symbols.
> > Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> process_pending_assemble_externals will be called at the end,
> which calls assemble_external_real on all external symbols.
> Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't
> assemble_external_real handle it?
Look at, e.g., mcore_external_libcall
Paolo Carlini <[EMAIL PROTECTED]> writes:
> Therefore, I'd like to apply to mainline the below (finishing testing
> on x86-linux), can you check it?
>
> Thanks in advance,
> Paolo.
>
> /
> 2007-01-15 Ian Lance Taylor <[EMAIL PROTECTED]>
> Paolo Carlini <[EMAIL PROTECTED]
Hello,
with the changes to the build system in the last few months, I am having
problems to do some things I am used to do during development. I found
more or less satisfactory procedures for most them, however, I would
like to know the "official" way how to achieve those effects (and to put
the
On Mon, Jan 15, 2007 at 09:47:34PM +0100, Toon Moene wrote:
> Grigory,
>
> Calculix is a combined C/Fortran program. Did you try to compile the
> Fortran parts with --param max-aliased-vops= default 50> ?
>
> Diego up'd the default from 10 to 50 because one (or more) of the
> (Fortran) Polyhed
Snapshot gcc-4.1-20070115 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070115/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Gabriel Dos Reis wrote:
| Therefore, I'd like to apply to mainline the below (finishing testing on
| x86-linux), can you check it?|
it is troublesome that we have managed to duplicate the same construct
twice.
Yes, I guess Benjamin may clean-up that stuff further, it belongs to
ext/pb_ds. T
On Mon, 15 Jan 2007, Paolo Carlini wrote:
| Ian Lance Taylor wrote:
[...]
Thanks. That escaped me because those bits were contributed by
knowledgeable GCC contributors, so I trusted them :-)
|
| >One way to write this expression in a fully defined manner is:
| >(T)1 << 30) - 1) << 1) +
Ian Lance Taylor wrote:
One way to write this expression in a fully defined manner is:
(T)1 << 30) - 1) << 1) + 1)
Thanks Ian.
Therefore, I'd like to apply to mainline the below (finishing testing on
x86-linux), can you check it?
Thanks in advance,
Paolo.
/
2007-01-15
Gabriel Dos Reis wrote:
The system_header pragma + template issue is separate, and I thought
it was resolved a long time ago -- apparently no. It is related to
our failure to copy a bit from a template _DECL.
Thanks, can you look a bit more into it?
Paolo.
On Mon, 15 Jan 2007, Paolo Carlini wrote:
| About the library itself, I'm also concerned by the weakness of our
| pragma system_header vs templates, which makes the whole warning game
| always very dangerous...
The system_header pragma + template issue is separate, and I thought
it was resolved a
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Paolo Carlini <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | >Specifically, for PR 30465 "((T)1 << 31) - 1" is potentially undefined
> | >when T is a 32-bit signed type, but well-defined if T is unsigned or
> | >wider than 32-bits.
> | >
> | FYI: this
Grigory,
Calculix is a combined C/Fortran program. Did you try to compile the
Fortran parts with --param max-aliased-vops=default 50> ?
Diego up'd the default from 10 to 50 because one (or more) of the
(Fortran) Polyhedron benchmarks showed a dramatic performance regression.
(Note: I've se
Roberto Bagnara wrote:
Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there plans to
fix this b
Ferad Zyulkyarov wrote:
type_id = get_identifier("MyType");
type_node = make_node(POINTER_TYPE);
TYPE_NAME(type_node) = type_id;
var_decl = build(VAR_DECL, get_identifier("t"), type_node);
Best way to figure this out is to write a simple 5 line testcase that
defines a structure type and also d
ying lcs wrote:
Can you please tell me if there is any performance gain in the output
program if i switch from gcc 3.4 to gcc 4.1 on Red hat Enterprise
linux 4?
Performance varies greatly from one application to the next. The only
way to tell if you will see a performance gain with your appli
Joe Buck wrote:
In the case of the containers, we are asserting/relying on the fact that
the pointer difference is zero or positive. But this has become a
widespread idiom: people write their own code in the STL style. If STL
code now has to be fixed to silence warnings, so will a lot of user
On Mon, Jan 15, 2007 at 10:24:40AM -0600, Gabriel Dos Reis wrote:
> Paolo Carlini <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Let's wait a bit more for other opinions, say one day or two, then I
> | will start the actual work. As far as I can see, other compilers do
> | not warn in such cases, an
I have posted a new wiki intended to help port maintainers with issues
that may arise with the dataflow branch. The new wiki page can be found
at http://gcc.gnu.org/wiki/DataflowPorting.
Thanks,
Kenny
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| In summary, for v3, one possibility could be combining the two
| quantities, consistently for all the containers, thus, essentially,
| compute container::max_size as min(allocator::max_size,
| numeric_limits::max) (all the computations modulo
| si
Paolo Carlini wrote:
So, yes, you can add the casts as a temporary work-around.
By the way, probably now I see why you consider the two issues related
and (some) casts temporary: in the case of vector, for example (not in
the case of deque) we are currently using in many places size_type,
w
Gabriel Dos Reis wrote:
| However, in order not to mix different issues, I think we should try
| first to resolve the much more limited issue at hand, which, I note,
| has to do with *deallocation*, not with *allocation*.
By the time we deallocate, any possible damage has already be done :-)
So
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| >My concern is for vectors whose size() exceeds
| > numeric_limits::max() -- even if we would like to
| > avoid the general discussion. My understanding -- and I would like
| > to hear of others' -- is that the
| >semantics description in the tab
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> I tried to build java yesterday:
[...]
BTW this is now PR 30454.
Tom
Gabriel Dos Reis wrote:
| Coming to the specific issue, and *assuming* we agree about the
| usefulness of warning for signed -> unsigned, maybe we are "lucky", in
| this sense: Table 65 says *explicitely* that size_type can represent
| any non-negative value of difference_type. Thus, as I see th
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| I vote against adding Wconversion to Wall before 4.3 is branched.
We are not in voting mode yet :-)
-- Gaby
On 15/01/07, Martin Sebor <[EMAIL PROTECTED]> wrote:
Paolo Carlini wrote:
>
> Anyway, note that our -Wconversion is not part of -Wall, not even
> -Wextra: are you maintaining that probably the bits having to do with
> float <-> integer should also be part of -Wall or at least -Wextra?
We use bot
Andrew Haley <[EMAIL PROTECTED]> writes:
| Paolo Carlini writes:
| > Andrew Haley wrote:
| >
| > > > Ok, I believe you. However, isn't true that, in general, because the
| > > > sign of the result is implementation defined,
| > >
| > >The sign of the result of % is no longer (since C99) im
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Gaby,
|
| >There is something that we knoq about the code, that the compiler
| >does not have: we expect a sequence denoted by its first and last
| >element, so that the difference is always positive. However, the
| >difference of pointers is define
Paolo Carlini wrote:
Martin Sebor wrote:
FYI: HP aCC warns for some but not all of these types of lossy
initializations. For example, a double to int conversion emits
a warning but ptrdiff_t to size_t or other signed to unsigned
conversions do not, probably because they're so common. I find
thi
Hi Gaby,
There is something that we knoq about the code, that the compiler
does not have: we expect a sequence denoted by its first and last
element, so that the difference is always positive. However, the
difference of pointers is defined in the language as an ptrdiff_t (a
signed type). No wo
Andrew Haley <[EMAIL PROTECTED]> writes:
| Paolo Carlini writes:
| > Andrew Haley wrote:
| >
| > > > Ok, I believe you. However, isn't true that, in general, because the
| > > > sign of the result is implementation defined,
| > >
| > >The sign of the result of % is no longer (since C99) im
Paolo Carlini writes:
> Andrew Haley wrote:
>
> > > Ok, I believe you. However, isn't true that, in general, because the
> > > sign of the result is implementation defined,
> >
> >The sign of the result of % is no longer (since C99) implementation-
> >defined.
> >
> >
> I see. However
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| Let's wait a bit more for other opinions, say one day or two, then I
| will start the actual work. As far as I can see, other compilers do
| not warn in such cases, and adding casts (*) isn't the cleanest
| practice in the world, thus my caution..
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Manuel,
|
| >> in a nutshell, what is happening is that a difference of two pointers is
| >> assigned to an unsigned variable. First blush, the warning seems to me a
| >> bit overzealous, but if we concur that this is what we *really* want for
| >> 4
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Gerald,
|
| >I noticed that -Wconversion now issues warnings in libstdc++.
| >
| in a nutshell, what is happening is that a difference of two pointers
| is assigned to an unsigned variable. First blush, the warning seems to
| me a bit overzealous, bu
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| >Specifically, for PR 30465 "((T)1 << 31) - 1" is potentially undefined
| >when T is a 32-bit signed type, but well-defined if T is unsigned or
| >wider than 32-bits.
| >
| FYI: this specific issue arises from std::numeric_limits on
| x86-linux:
process_pending_assemble_externals will be called at the end,
which calls assemble_external_real on all external symbols.
Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't
assemble_external_real handle it?
H.J.
Andrew Haley wrote:
> Ok, I believe you. However, isn't true that, in general, because the
> sign of the result is implementation defined,
The sign of the result of % is no longer (since C99) implementation-
defined.
I see. However, by default, I'm always talking about C++03...
Paolo.
Paolo Carlini writes:
> Roberto Bagnara wrote:
>
> > No, Paolo: the result of INT_MIN % -1 is zero, according to the standard.
> > There is no overflow whatsoever involved. The overflow that you
> > see is simply an artifact of GCC that produces assembly code that
> > does not implement rem
Roberto Bagnara wrote:
No, Paolo: the result of INT_MIN % -1 is zero, according to the standard.
There is no overflow whatsoever involved. The overflow that you see is
simply an artifact of GCC that produces assembly code that does not
implement
remainder expressions correctly.
Ok, I believ
Andrew Haley wrote:
Roberto Bagnara writes:
>
> Reading the thread "Autoconf manual's coverage of signed integer
> overflow & portability" I was horrified to discover about GCC's
> miscompilation of the remainder expression that causes INT_MIN % -1
> to cause a SIGFPE on CPUs of the i386 f
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Manuel López-Ibáñez wrote:
|
| >> Sorry, please disregard my message: I was inadvertently using an old
| >> compiler (2007-01-06)
| >
| > So now you are getting both warning messages?
|
| Definitely I'm getting both:
|
| warning.cc: In function 'int m
Paolo Carlini wrote:
Andrew Haley wrote:
Paolo Carlini writes:
> > I would like to understand the issue better, however...
What more is there to understand? It's an integer overflow. The
processor generates a trap on integer overflows during division
operations.
Yes, sorry, now I see that
On 15 January 2007 15:02, ying lcs wrote:
> Hi,
>
> Can you please tell me if there is any performance gain in the output
> program if i switch from gcc 3.4 to gcc 4.1 on Red hat Enterprise
> linux 4?
>
> Thank you.
Yes, you can expect at least a 20dB gain in SNR, a 12% increase in miles per
Hi,
Can you please tell me if there is any performance gain in the output
program if i switch from gcc 3.4 to gcc 4.1 on Red hat Enterprise
linux 4?
Thank you.
Hi!
There is a huge regression of gcc 4.3 performance detected on
cpu2006/454.calculix benchmark at -O2 optimization level on
x86_64-redhat-linux.
Regression is caused by mem-ssa merge 12/12/2006 (revision 119760).
http://gcc.gnu.org/viewcvs?view=rev&revision=119760
PS: I'm trying to get a sm
Andrew Haley wrote:
Paolo Carlini writes:
>
> I would like to understand the issue better, however...
What more is there to understand? It's an integer overflow. The
processor generates a trap on integer overflows during division
operations.
Yes, sorry, now I see that in the specific cas
Andrew Haley wrote:
Paolo Carlini writes:
>
> I would like to understand the issue better, however...
What more is there to understand? It's an integer overflow. The
processor generates a trap on integer overflows during division
operations.
Just because the wrong code is generated for t
Paolo Carlini writes:
>
> I would like to understand the issue better, however...
What more is there to understand? It's an integer overflow. The
processor generates a trap on integer overflows during division
operations.
Andrew.
Roberto Bagnara writes:
>
> Reading the thread "Autoconf manual's coverage of signed integer
> overflow & portability" I was horrified to discover about GCC's
> miscompilation of the remainder expression that causes INT_MIN % -1
> to cause a SIGFPE on CPUs of the i386 family. Are there plans
Hi Roberto,
Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there plans to
fix this bug (which,
Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there plans to
fix this bug (which, to me, looks
On 1/15/07, pranav bhandarkar <[EMAIL PROTECTED]> wrote:
Hello Everyone,
I have the following source code
static int i;
static char a;
char foo_gen(int);
void foo_assert(char);
void foo ()
{
int *x = &i;
a = foo_gen(0);
a |= 1; /* 1-*/
if (*x) goto end:
a | =1; /* --
Hi again,
I think that the type of type_node is missing. Try to add
TREE_TYPE (type_node); For example TREE_TYPE (type_node) =
integer_type_node. (if MyType is int).
"MyType" is a struct (of other again coumpound types) and will not
work with already existing type nodes like integer_type_node
Hello Everyone,
I have the following source code
static int i;
static char a;
char foo_gen(int);
void foo_assert(char);
void foo ()
{
int *x = &i;
a = foo_gen(0);
a |= 1; /* 1-*/
if (*x) goto end:
a | =1; /* -2--*/
foo_assert(a);
end:
return;
}
Now I expect th
> tree type_id, type_node, var_decl;
>
> type_id = get_identifier("MyType");
> type_node = make_node(POINTER_TYPE);
> TYPE_NAME(type_node) = type_id;
> var_decl = build(VAR_DECL, get_identifier("t"), type_node);
>
> But, when I compile my source with the modified GCC (as above) I get
> an error:
Hi,
When the code is being parsed in c-parser.c I try to transparently
create a variable declaration of custom type within the code being
compiled. The name of the custom type is "MyType" (defined in some
header file by typedef).
In my source file I have a function:
void foo()
{
...;
}
At the
Martin Sebor wrote:
FYI: HP aCC warns for some but not all of these types of lossy
initializations. For example, a double to int conversion emits
a warning but ptrdiff_t to size_t or other signed to unsigned
conversions do not, probably because they're so common. I find
this behavior useful.
T
On 15/01/07, Roger Sayle <[EMAIL PROTECTED]> wrote:
The second issue is that there are two different overflow related
warnings. The first warning indicates that an overflow has occurred in an
expression, and the second is that the overflowed result is used in a
context required
to be a compile
Hi Roger
and thanks for your explanations. Just a couple of additional remarks.
I agree with Paolo that this is a change for C++, and should at least be
documented in changes.html, and probably be tweaked to avoid warning in
system headers.
Note that, AFAICS, the issue would boil down to fix
YO buddy
Don't tell me why your ramrod is so small,
I will better help you to make it really Bigger!
Why bigger? Because over 80% of all women need a longer
sausage to satisfy their desire!
Go there and get your solution: http://alnagleen.info
It'll really help you!
We will ship it worldwide
68 matches
Mail list logo
