> >and, for diagnostics with line number information, doing the lookup
> >to see what was in effect at that line. But the complications are
> >worse than the benefits.
>
> Can you explain the complications you see. This seems like the way
> to go to me, because it guarantees that the effect is pr
DJ Delorie wrote:
I had thought of keeping a table of pragma-settings-by-line-number
and, for diagnostics with line number information, doing the lookup to
see what was in effect at that line. But the complications are worse
than the benefits.
Can you explain the complications you see. Thi
> Longer term, I'd like to be able to control warnings on a line by
> line basis. The ability to say "I've examined this expression /
> line / block / whatever of code and I'm happy with it with-regard-to
> warning XYZ, please be quiet" would be very valuable.
>
> Based on Gaby's comments, it so
> Date: Mon, 9 Jan 2006 14:30:03 -0500
> From: DJ Delorie <[EMAIL PROTECTED]>
> > . Next, if it would not be rejected on the "we don't want to have such
> > functionality" basis, then the question becomes one of what should the
> > interface look like? Some possibilities include:
> >
> > #pr
> GCC's current architecture, heavily relying on global states, is not
> yet prepared to consistently support such feature -- even though the
> sole diagnostic machinery might be somewhat prepared for that.
Yes, we've covered this a couple of times before. There's a limited
set of things we can
> Date: Mon, 9 Jan 2006 11:13:22 -0800
> From: Joe Buck <[EMAIL PROTECTED]>
>
> On Mon, Jan 09, 2006 at 01:46:21PM -0500, David Taylor wrote:
> > For a variety of reasons, we would like to be able to specify
> > individual compilation switches *within* individual files.
>
> You don't need a gcc m
Hello!
Checking the linux configs for different archs only arm has
%{symbolic:-Bsymbolic} for linking.
Is arm out of date, or should the others been updated?
Thanks, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Hello!
patch for m68k to handle PIC as the other archs
Please apply, thx, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
--- gcc-4.0.2/gcc/config/m68k/linux.h.mps 2006-01-08 23:02:06 +0100
+++ gcc-4.0.2/gcc/config/
Robert Dewar <[EMAIL PROTECTED]> writes:
| DJ Delorie wrote:
|
| >I had planned on forcing the user to place these pragmas before the
| >first function definition, otherwise it becomes difficult to track
| >when various warnings are in force.
| >
| For warnings, it is definitely useful to be able
On Jan 9, 2006, at 2:46 PM, Diego Novillo wrote:
On Monday 09 January 2006 14:42, Andrew Pinski wrote:
the only passes which do run are cfg creation, expand, and maybe a
couple other simple ones.
I know that. It's expand the one bothering me. Are we issuing errors
that
late in the pipeli
On Monday 09 January 2006 14:42, Andrew Pinski wrote:
> the only passes which do run are cfg creation, expand, and maybe a
> couple other simple ones.
>
I know that. It's expand the one bothering me. Are we issuing errors that
late in the pipeline?
Diego Novillo <[EMAIL PROTECTED]> writes:
| I hit an ICE inside an optimizer pass because the code had a glaring syntax
| error that we diagnosed correctly, but since we kept going, the
| transformation didn't find the CFG in the assumed state, causing the ICE.
|
| Is there any reason in partic
>
>
> I hit an ICE inside an optimizer pass because the code had a glaring syntax
> error that we diagnosed correctly, but since we kept going, the
> transformation didn't find the CFG in the assumed state, causing the ICE.
We do stop the optimization passes from running in general.
/* Gate: e
DJ Delorie <[EMAIL PROTECTED]> writes:
| > . Next, if it would not be rejected on the "we don't want to have such
| > functionality" basis, then the question becomes one of what should the
| > interface look like? Some possibilities include:
| >
| > #pragma GCC command-line -Wprecision-misma
DJ Delorie wrote:
I had planned on forcing the user to place these pragmas before the
first function definition, otherwise it becomes difficult to track
when various warnings are in force.
For warnings, it is definitely useful to be able to use them on a fine
grained basis in the
source. One
I hit an ICE inside an optimizer pass because the code had a glaring syntax
error that we diagnosed correctly, but since we kept going, the
transformation didn't find the CFG in the assumed state, causing the ICE.
Is there any reason in particular we don't just make the gate functions
return f
> . Next, if it would not be rejected on the "we don't want to have such
> functionality" basis, then the question becomes one of what should the
> interface look like? Some possibilities include:
>
> #pragma GCC command-line -Wprecision-mismatch
>
> unilaterally set -Wprecision-mismatch
On Mon, Jan 09, 2006 at 01:46:21PM -0500, David Taylor wrote:
> For a variety of reasons, we would like to be able to specify
> individual compilation switches *within* individual files.
You don't need a gcc modification to do that; you can arrange to get
the compiler flags from a comment in the f
Hi,
in file 'bt-load.c', in function 'augment_live_range', some memory is
xmalloc'ed. It seems to be possible to never free it, if all the first tests
are true.
Yhe memory is only freed once at the end of the function.
CJ
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
David Taylor wrote:
. For starters, does this sound reasonable? That is, if I implemented
this, and we contributed it back, would it be considered? Or would it
likely be rejected out of hand?
To me, it seems better to handle this in the external environment with
appropriate
build tools. Fo
For a variety of reasons, we would like to be able to specify
individual compilation switches *within* individual files.
When building we specify a large number of compilation options. But,
some files need tweaks of one sort or another to the generic set of
options.
Most of the tweaks involve tu
This is a severe, but very rare, bug in combine, that one of the recent
changes have exposed. I don't know which.
Basically, combine will not try combining across call instructions, but
on the other hand it will not invalidate equivalences with registers
that are explicitly set in the call in
Piotr,
Hello. First, a note: you should be sending libstdc++ mail to the
[EMAIL PROTECTED] list.
I haven't verified your claim, but if it is true, I would suggest the
following actions on your part to solve it:
1) enter a sparc backend bug in gcc bugzilla about not defining __sparcv9 in 32
bit
Greetings.
Has anyone done or is aware of static coverage analysis tools that
can be used with GCC? I know that people have used 'gcov' with the
Linux kernel and User Mode Linux (UML) to do analysis with the
kernel. I actually want to do coverage analysis on bootloader code
from YAMON (used mostly
On Mon, 9 Jan 2006, Jakub Jelinek wrote:
> On Mon, Jan 09, 2006 at 02:38:17PM +0100, Peter S. Mazinger wrote:
> > for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
> > would be
> > %{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
> > %{ffast-math|funsafe-math-optimizatio
On Mon, 2006-01-09 at 08:22 +0530, Ranjit Mathew wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> However, it still remains true that the code path
> I referred to is wrong and if, as you say, it can
> never be taken, it should just be removed and
> replaced with an assertion codifying w
Kazu Hirata wrote:
Notice that match_code at the beginning does not mention PARALLEL, but
we have GET_CODE (op) != PARALLEL later. Is this predicate intended
to accept PARALLEL as well?
Yes, it is.
If so, should we change the match_code at
the beginning?
Yes.
On Mon, Jan 09, 2006 at 02:38:17PM +0100, Peter S. Mazinger wrote:
> for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
> would be
> %{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
> %{ffast-math|funsafe-math-optimizations:%:if-exists(crtfastmath.o%s)}
That's IMHO a bad
Hello!
Would the attached patch be acceptable?
The gcc.c patch part should really go to gcc/config/linux.h, but sadly not
all archs include that file.
for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
would be
%{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
%{ffast-m
29 matches
Mail list logo
