On 27 Mar 2007 21:11:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| In C, a pedwarn is a warning by default, an error with -pedantic-errors.
|
| In C++, a pedwarn is an error by default, a warning with -fpermissive.
You're describing a defect, not the intended semantics.
In C, a pedwar
Ok, I suppose, as long as the backticks still get expanded.
On Tue, Mar 27, 2007 at 10:40:10PM -0400, DJ Delorie wrote:
>
> > I only meant:
> >
> > CROSS_SYSTEM_HEADER_DIR='$(shell echo "$(gcc_tooldir)/sys-include")'
>
> I figured you meant that. Can you think of an example that would
> benefit from this quoting?
$(gcc_tooldir) starts with $(libsubdir)
> I only meant:
>
> CROSS_SYSTEM_HEADER_DIR='$(shell echo "$(gcc_tooldir)/sys-include")'
I figured you meant that. Can you think of an example that would
benefit from this quoting?
On Tue, Mar 27, 2007 at 10:28:33PM -0400, DJ Delorie wrote:
>
> > On Tue, Mar 27, 2007 at 03:01:04PM -0400, DJ Delorie wrote:
> > > - CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
> > > + CROSS_SYSTEM_HEADER_DIR='$(shell echo $(gcc_tooldir)/sys-include)'
> >
> > Don't you need more quotes
> On Tue, Mar 27, 2007 at 03:01:04PM -0400, DJ Delorie wrote:
> > - CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
> > + CROSS_SYSTEM_HEADER_DIR='$(shell echo $(gcc_tooldir)/sys-include)'
>
> Don't you need more quotes than that?
I think if we quoted it more, we'd end up passing the backti
On Tue, Mar 27, 2007 at 03:01:04PM -0400, DJ Delorie wrote:
> - CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
> + CROSS_SYSTEM_HEADER_DIR='$(shell echo $(gcc_tooldir)/sys-include)'
Don't you need more quotes than that?
--
Daniel Jacobowitz
CodeSourcery
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
|
| > my understanding of pedwarn (since over a decade) is I explained.
| > Now, if we do have some good diagnostics, we should not lose them,
| > as a matter of restoring the traditional meaning of pedw
On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
> my understanding of pedwarn (since over a decade) is I explained.
> Now, if we do have some good diagnostics, we should not lose them,
> as a matter of restoring the traditional meaning of pedwarns.
> Do you have an approximate list of those diagnost
On Wed, Mar 28, 2007 at 01:23:45AM +, Joseph S. Myers wrote:
> In C, a pedwarn is a warning by default, an error with -pedantic-errors.
>
> In C++, a pedwarn is an error by default, a warning with -fpermissive.
OK, so the change is that pedwarns from the preprocessor were previously
warnings
Quoting Manuel López-Ibáñez <[EMAIL PROTECTED]>:
On 27 Mar 2007 11:53:18 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel L=F3pez-Ib=E1=F1ez wro=
te:
| > On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]
2007/3/28, Andreas Schwab <[EMAIL PROTECTED]>:
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> The range of long should be -(2^63) .. +((2^63)-1).
Your long has only 32 bits.
> For shifts, the range of a long type should be 0 .. 64 (65 values), not 0 ..
31.
Your long has only 32 bits.
>> %ld
27 Mar 2007 16:35:16 -0700, Ian Lance Taylor <[EMAIL PROTECTED]>:
You are confusing long and long long. This is C, not Java. The
suffix for a long long constant is LL, not L.
Very thanks, LL and %lld are the solution. The GCC compiler has not
bugs that i said.
testing_long_GCC_march2007_3.t
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> The range of long should be -(2^63) .. +((2^63)-1).
Your long has only 32 bits.
> For shifts, the range of a long type should be 0 .. 64 (65 values), not 0 ..
> 31.
Your long has only 32 bits.
>> %ld is not the correct format for a value of type l
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> > > 1. Error and Warning in assignment of a long constant (with L letter)
> > > (it's not true that a = 1410065408, high(a) = 0x).
> >
> > The constant overflows the range of long, causing undefined behaviour.
>
> The range of long should be -(
2007/3/28, Andreas Schwab <[EMAIL PROTECTED]> wrote:
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> Brief summary, there are 3 bugs:
None of them are bugs in the compiler, only in your program.
Sure? My program is a testsuite of why the long type doesn't work, no
why my program doesn't work.
Hi people,
bug_mult_and_shift_long.c
-
#include // it's for public domain by J.C. Pizarro, hahahahaha
int main() {
long long int a,b,c;
unsigned int hi_a,lo_a,hi_b,lo_b,hi_c,lo_c;
a = 100L; // 10G
b = 1L; // 100M
c = a * b;
hi_a = (((unsigned long)a
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> Brief summary, there are 3 bugs:
None of them are bugs in the compiler, only in your program.
> 1. Error and Warning in assignment of a long constant (with L letter)
> (it's not true that a = 1410065408, high(a) = 0x).
The constant overflows
On 27 Mar 2007 11:53:18 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
| > On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
| > >* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007
On 27/03/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
> On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> >* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:08]:
> >> C++ preprocessor emits errors by default for nonco
Hi people,
bug_mult_and_shift_long.c
-
#include // it's for public domain by J.C. Pizarro, hahahahaha
int main() {
long long int a,b,c;
unsigned int hi_a,lo_a,hi_b,lo_b,hi_c,lo_c;
a = 100L; // 10G
b = 1L; // 100M
c = a * b;
hi_a = (((unsigned
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Doh. Yes, we'd need immediate evaluation *and* $(shell ...).
I think it's *or* not *and*. How about this? Seems to work for me.
Index: configure.ac
===
--- configure.ac(revision
On Tue, 27 Mar 2007, Michael Meissner wrote:
> translation (5.1.1.2 in the C99 standard, should be close in the C90
> standard). In particular, in paragraph 3, it says:
>
> A source file shall not end in a partial preprocessing token or a
> partial comment...
>
> If there is
Dave Korn wrote:
> On 27 March 2007 18:25, Andreas Schwab wrote:
>
>> "Dave Korn" <[EMAIL PROTECTED]> writes:
>>
>>> Or how about using ':=' to force immediate evaluation?
>> That won't help, since backquotes are only expanded by the shell, not by
>> make.
>
> Doh. Yes, we'd need immediate e
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Now that the gcc 4.2 release is getting closer, I am resending this
> e-mail from Martin Michlmayr. I've removed options which I believe
> are sufficiently internal to not require mention in the changes file,
> and I've removed options which are now d
Jupming in at a random point.
First, unless my memory is completely faulty, Stan Cox should be named
in this change too. ISTR he did the initial implementation for one
particular coprocessor, which we later generalised to cover other user-
configurable coprocessors. However, as DJ says, it's bee
On Tue, Mar 27, 2007 at 09:47:35AM -0700, Joe Buck wrote:
> On Tue, Mar 27, 2007 at 02:11:21PM +0100, Manuel López-Ibáñez wrote:
> > On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> > >* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:01]:
> > >> >Thanks for the explanation - this
On 27 March 2007 18:25, Andreas Schwab wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> Or how about using ':=' to force immediate evaluation?
>
> That won't help, since backquotes are only expanded by the shell, not by
> make.
Doh. Yes, we'd need immediate evaluation *and* $(shell ..
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Or how about using ':=' to force immediate evaluation?
That won't help, since backquotes are only expanded by the shell, not by
make.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg,
On 27 March 2007 17:55, DJ Delorie wrote:
> When cross compiling with a sysroot, you sometimes end up with nested
> backticks.
>
> The case we're seeing it with is m32r-elf, where gcc_tooldir is defined
> thusly:
>
> gcc_tooldir = $(libsubdir)/$(unlibsubdir)/`echo $(exec_prefix) | sed -e
> 's|
When cross compiling with a sysroot, you sometimes end up with nested backticks.
The case we're seeing it with is m32r-elf, where gcc_tooldir is defined thusly:
gcc_tooldir = $(libsubdir)/$(unlibsubdir)/`echo $(exec_prefix) | sed -e
's|^$(prefix)||' -e 's|/$(dollar)||' -e 's|^[^/]|/|' -e
's|/[
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
| > On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
| > >* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:08]:
| > >> C++ preprocessor emits errors by default for nonconform
* Ian Lance Taylor:
> I don't think we necessarily have to change anything.
Yes, I think that the standard does not require a particular approach
to this problem.
> But I think that Florian's point is that we don't have to confuse the
> concrete implementation with the abstract source representa
On Tue, Mar 27, 2007 at 02:11:21PM +0100, Manuel López-Ibáñez wrote:
> On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> >* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:01]:
> >> >Thanks for the explanation - this explains what I'm seeing. Is there
> >> >a good reason against ch
On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
> On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> >* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:08]:
> >> C++ preprocessor emits errors by default for nonconformant code,
> >> following the C++ frot-end defa
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> | Neither the C standard nor the C++ standard imposes any requirements
> | on concrete source code representation, so it's not quite right to
> | blame this issue on nonconformant code.
>
> I don't unde
On Mar 27, 2007, at 8:35 AM, [EMAIL PROTECTED] wrote:
I'm currently working in a company, as embedded developper, which
use gnu
tools. I have a good experience about non gnu compiler tools and i
need
help because the most disavantage of gcc compiler is the almost
unexistant
support for deve
On Mar 26, 2007, at 9:28 PM, DJ Delorie wrote:
No, it's more like this:
typedef int copsi __attribute__((mode(COPSI)));
void foo (int *a, copsi *b, int i)
{
while (i--)
{
*a *= 2;
*b *= 2;
}
}
This will keep both the core multiplier and the coprocessor multiplier
busy.
:-( Wou
Florian Weimer <[EMAIL PROTECTED]> writes:
| * Manuel López-Ibáñez:
|
| > C++ preprocessor emits errors by default for nonconformant code,
| > following the C++ frot-end default behaviour.
|
| Neither the C standard nor the C++ standard imposes any requirements
| on concrete source code represen
* Manuel López-Ibáñez:
> C++ preprocessor emits errors by default for nonconformant code,
> following the C++ frot-end default behaviour.
Neither the C standard nor the C++ standard imposes any requirements
on concrete source code representation, so it's not quite right to
blame this issue on non
[EMAIL PROTECTED] writes:
> Hi everybody,
>
> I'm currently working in a company, as embedded developper, which use gnu
> tools. I have a good experience about non gnu compiler tools and i need
> help because the most disavantage of gcc compiler is the almost unexistant
> support for developper.
R
Martin Michlmayr <[EMAIL PROTECTED]> writes:
| * Gabriel Dos Reis <[EMAIL PROTECTED]> [2007-03-27 09:33]:
| > -pedantic asks for strict checking of rules. User should accept
| > correcting their codes (or used codes) with they ask for strict
| > checking.
|
| They didn't "ask" for it because G++
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > Martin Michlmayr <[EMAIL PROTECTED]> writes:
| >
| > | * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
| > | > So if you are seeing this in C++, the change was intentional because
| >
On 27/03/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 27 March 2007 16:07, Ian Lance Taylor wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
>> Martin Michlmayr <[EMAIL PROTECTED]> writes:
>>
>>> * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
So if you are seeing this i
Dear all,
I want to insert functions calls during a new pass. The problem is to
create parameters. At this time, I successfully create a function call
with two constante as parameter and insert it (I can see that in the
asm's code). But, I want to give the address of an array and a constante
Hi everybody,
I'm currently working in a company, as embedded developper, which use gnu
tools. I have a good experience about non gnu compiler tools and i need
help because the most disavantage of gcc compiler is the almost unexistant
support for developper.
I work on an embedded software for an
On 27 March 2007 16:07, Ian Lance Taylor wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
>> Martin Michlmayr <[EMAIL PROTECTED]> writes:
>>
>>> * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
So if you are seeing this in C++, the change was intentional because
PR2
* Gabriel Dos Reis <[EMAIL PROTECTED]> [2007-03-27 09:33]:
> -pedantic asks for strict checking of rules. User should accept
> correcting their codes (or used codes) with they ask for strict
> checking.
They didn't "ask" for it because G++ does it by default.
--
Martin Michlmayr
http://www.cyriu
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Martin Michlmayr <[EMAIL PROTECTED]> writes:
>
> | * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
> | > So if you are seeing this in C++, the change was intentional because
> | > PR24924 was fixed. If you are seeing it in C and you are
Martin Michlmayr <[EMAIL PROTECTED]> writes:
| * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
| > So if you are seeing this in C++, the change was intentional because
| > PR24924 was fixed. If you are seeing it in C and you are not using
| > pedantic-errors, then it is probably a bu
On 11/3/06, Ian Blanes <[EMAIL PROTECTED]> wrote:
The original author of this patch said he sent his copyright assignment. I
only did minor modification to his work so I don't I think I should send
it too.
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00833.html
There doesn't seem to be an assi
Jeffrey Law <[EMAIL PROTECTED]> writes:
> > > * expmed.c (expand_mult): If the variable operand is a coprocessor
> > > value, use a coprocessor accumulator.
> >
> > Why? Isn't this an architecture specific decision to make? Iff this
> > will ever be useful to other architectures tha
is there any other short-time plan to get
i386-linux bootstrap back?
Just configure gcc with --disable-decimal-float. I don't think
dfp works on x86 very well.
Thanks for suggesting --disable-decimal-float.
Note that, in my above sentence, "any other short-time plan" includes
disabling it by
On Tue, Mar 27, 2007 at 02:41:51PM +0100, Richard Guenther wrote:
> On 3/27/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >On Tue, Mar 27, 2007 at 12:28:18PM +0200, François-Xavier Coudert wrote:
> >> >My nightly bootstrap of mainline on i386-linux failed tonight, on
> >> >revision 123192.
> >>
> >> Th
On 3/27/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
On Tue, Mar 27, 2007 at 12:28:18PM +0200, François-Xavier Coudert wrote:
> >My nightly bootstrap of mainline on i386-linux failed tonight, on
> >revision 123192.
>
> This issue is still not fixed as of now. A diff was posted to PR31344
> with the me
On Tue, Mar 27, 2007 at 12:28:18PM +0200, François-Xavier Coudert wrote:
> >My nightly bootstrap of mainline on i386-linux failed tonight, on
> >revision 123192.
>
> This issue is still not fixed as of now. A diff was posted to PR31344
> with the mention "This isn't a real patch." Is a real patch
On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:08]:
> C++ preprocessor emits errors by default for nonconformant code,
> following the C++ frot-end default behaviour. Users can use the
> -fpermissive option to downgrade these diag
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:08]:
> C++ preprocessor emits errors by default for nonconformant code,
> following the C++ frot-end default behaviour. Users can use the
> -fpermissive option to downgrade these diagnostics from errors to
> warnings.
s/frot-end/front-end/
On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:01]:
> >Thanks for the explanation - this explains what I'm seeing. Is there
> >a good reason against changing this particular warning from
> >CPP_DL_PEDWARN to CPP_DL_WARNING? Quit
On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
> So if you are seeing this in C++, the change was intentional because
> PR24924 was fixed.
I think it would be worth mentioning this on
http://gcc.gnu.org/gcc-4.3/changes.html
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:01]:
> >Thanks for the explanation - this explains what I'm seeing. Is there
> >a good reason against changing this particular warning from
> >CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail
> >to build because of this
On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
> So if you are seeing this in C++, the change was intentional because
> PR24924 was fixed. If you are seeing it in C and you are not using
> pedantic-errors, then it is probably
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
> So if you are seeing this in C++, the change was intentional because
> PR24924 was fixed.
I think it would be worth mentioning this on
http://gcc.gnu.org/gcc-4.3/changes.html since quite a bit of C++ code
is affected by this change.
* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
> So if you are seeing this in C++, the change was intentional because
> PR24924 was fixed. If you are seeing it in C and you are not using
> pedantic-errors, then it is probably a bug.
Thanks for the explanation - this explains what I'
It is a pedantic warning. Pedantic warnings are warnings in C and
errors in C++, unless you use -fpermissive.
So if you are seeing this in C++, the change was intentional because
PR24924 was fixed. If you are seeing it in C and you are not using
pedantic-errors, then it is probably a bug.
Cheers
On 27 March 2007 11:26, Martin Michlmayr wrote:
> Between 4.3.0 20070303 and 4.3.0 20070326 the "no newline at end of
> file" warning changed to an error. Interestingly enough, I cannot see
> any obvious change to libcpp/lex.c or the ChangeLog.
>
> Does anyone else see this and know whether this
My nightly bootstrap of mainline on i386-linux failed tonight, on
revision 123192.
This issue is still not fixed as of now. A diff was posted to PR31344
with the mention "This isn't a real patch." Is a real patch planned in
the near future, or is there any other short-time plan to get
i386-linux
Between 4.3.0 20070303 and 4.3.0 20070326 the "no newline at end of
file" warning changed to an error. Interestingly enough, I cannot see
any obvious change to libcpp/lex.c or the ChangeLog.
Does anyone else see this and know whether this was intentional? I
think this change is a bad idea since
Andrea Callia D'Iddio wrote:
> I looked for "into" and "ssa" in passes.c, but I've not found
> anything.
"into" does not give much indeed. But ssa should point you to
pass_build_ssa and pass_del_ssa, which should reveal a lot.
> Also I tried with options -fdump-tree-ssa and -O1 but, when
> my pa
I looked for "into" and "ssa" in passes.c, but I've not found
anything. Also I tried with options -fdump-tree-ssa and -O1 but, when
my pass is executed, code is only in GIMPLE form (in this last case a
file with code in SSA form is written, but I don't need a file, I'd
like that basic blocks conta
70 matches
Mail list logo
