Re: [RFC] GCC caret diagnostics
Ian Lance Taylor <[EMAIL PROTECTED]> writes: >Another approach would be to only use the carets for parse errors, >which is where they are the most helpful. And preprocessor if possible [also sometimes I would love to have an option in gcc to just display the preprocessed input when something bad happens inside a macro. I usually do that from hand using gcc -E, but it would be cool if the compiler could do it automatically, ideally with carets] > What do other compilers do? Reopening the file doesn't work for > standard input, which I admit is an unusual case. I think it would be reasonable to just not display the carets if the input is not seekable. Surely qemu doesn't need carets for once. -Andi
Re: [RFC] GCC caret diagnostics
> Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > >Another approach would be to only use the carets for parse errors, > >which is where they are the most helpful. > > And preprocessor if possible > > [also sometimes I would love to have an option in gcc to just > display the preprocessed input when something bad happens inside > a macro. I usually do that from hand using gcc -E, but it would be cool > if the compiler could do it automatically, ideally with carets] > > > What do other compilers do? Reopening the file doesn't work for > > standard input, which I admit is an unusual case. > > I think it would be reasonable to just not display the carets > if the input is not seekable. Surely qemu doesn't need carets > for once. It seems to me that keeping whole input buffer in memory (that is often simply mmapped) is not bad option at all for a moment. Our memory consumption exceeds source of input program in most cases anyway and it ought to be very easy change in future. Adding support for releasing large buffers from memory and either seeking or not displaying carrets if it turns out to be important on the top of the in-memory implementation seems straighforward: the line location would be anyway something like file ID+offset in the file and it does not matter much if the underlying mechanism is memory buffer/mmap area or seek&read. Implementing something like file compression seem bit expensive approach for me. Lexing+parsing is slow enough. Honza > > -Andi
Re: [RFC] GCC caret diagnostics
Ian> For a middle-end error like Ian> "assuming signed overflow does not occur when simplifying Ian> multiplication" a caret pointer might be more misleading than Ian> otherwise, as one thing we know for sure is that it would not point at Ian> a multiplication operator. Chris> An important class of middle-end warnings is use of undefined values Chris> and other dataflow warnings in GCC. Yes, this is what I was thinking about as well. Ian> What do other compilers do? Reopening the file doesn't work for Ian> standard input, which I admit is an unusual case. We have many options here of course. We can write stdin to a file. We could keep the buffer around in this one specific case and have a special case in the code. We could say "-fshow-caret is not supported with stdin". Perhaps I was mistaken to state an implementation preference this early, anyway. It would be fine by me to have an implementation that works in any reasonable way. If the "don't free" approach proves too costly, with sane API design we will know we can always rip it out and go with "reopen and seek". Tom
Re: [RFC] GCC caret diagnostics
> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes: Andi> [also sometimes I would love to have an option in gcc to just Andi> display the preprocessed input when something bad happens inside Andi> a macro. I usually do that from hand using gcc -E, but it would be cool Andi> if the compiler could do it automatically, ideally with carets] I've wanted this from time to time as well. Would you mind filing an enhancement request for this? Tom
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Mar 6, 2008, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> It's extremely rare, no doubt about it. It's just that it *yells*
> security issue in the making. It's not a source bug, i.e. not easily
> reviewable. It's related to signal handlers which are the mark of a
> server and/or more failure-conscious program than usual. It's obscure
> (breaking a stringop, probably memset, or a not-paranoid-enough inline
> asm in a signal handler through a running memmove in the main program,
> oh my) but reasonably predictable for someone looking for an
> exploitable flaw.
> It's gcc's job to adapt to the realities of its running environment,
> not the other way around.
I smell a false dilemma here.
The problem doesn't have to be fixed/worked-around in either the
kernel or GCC. Per your argument, one might claim it's the userland
library's, or even the application's job to adapt to the realities of
its running environment.
GCC doesn't know what functions are signal handlers to insert cld in
them. How could it fix the problem, then? How could it possibly fix
custom assembly? How could it possibly fix object code containing
signal handlers, compiled by other compilers?
A userland system library, in theory, knows what functions are signal
handlers. It could wrap function pointers passed as arguments to
signal() such that they get cld. But then, applications that couldn't
care less about this would take a hit.
Applications, on the other hand, know when they might need cld. So,
per your argument, they should adapt to the realities of their running
environment, and add asm("cld"); to signal handlers that might need
it. At times, it may be hard for them to know whether they need it,
because too many factors may affect this need. E.g.:
- if the kernel does cld for them, then they don't need it. But
that's a run-time property, so it can't be tested at build time: the
code may run on a different kernel that doesn't do it.
- if none of the libraries they use mess with this flag, or none of
the libraries they use from signal handlers depend on this flag, then
they don't need it. But then, again, libraries may vary over time,
and you can't assume the (dynamic) library that's available at build
time will behave the same way at run time.
So an application would have to do it conservatively, adding cld to
their signal handlers just in case.
But then, it would be more convenient if the library did it.
And then, by the same argument, it would be more convenient if the
kernel did it.
(Compiler can't do it, since it doesn't know what's a signal handler
in the general case.)
And that's an argument to support the ABI specs as they are.
It would be just silly to try to work around this deviation from the
specs, at a performance penalty, in every affected compiler, library
*and* application. And anything less than fixing all of them would be
an incomplete work around.
Which is not an argument against providing work arounds where
possible, just an argument in favor of fixing the problem where it can
be fixed for good.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: birthpoints in rtl.
On Mar 4, 2008, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Richard Sandiford wrote: >> If we went for an explicit move, I assume we would either have to >> (a) discount hard regs that can't be moved, (b) force backends to >> allow all no-op moves or (c) circumvent the backend somehow. > From my point of view, this is a killer argument that if we want to > build fuds/birthpoints for all regs, the info must be on the side. Nah. It can't be too hard to implicitly insert a (set (match_operand 0 "anything_goes_p" "X") (match_dup 0)) pattern in every back end, even behind the scenes. We might as well do this for USEs, CLOBBERs, ASMs (and DEBUG_INSNs), and phase out some of the special treatment they get at various places for not being recognizable. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Constrain valid arguments to BIT_FIELD_REF
On Mar 4, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> the type of the result is unspecified.
??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm
pretty sure that's what specifies the type of the result.
> I suggest to make sure that bit position and size are constants,
+1
> the object referenced is of integral type
This would break the use of SRA to extract sub-objects of non-integral
type. IIRC Ada does such things.
> the result type is of the same type as the operand zero type
Err, this doesn't make much sense to me. Consider:
struct {
int i:3;
unsigned j:5;
} k;
int foo(int x, unsigned y)
k.i = x;
k.j = y;
bar ();
return k.i + k.j;
}
Now, I want to extract i or j from k. For starters, k's type is
not an integral type. i and j are components in the same word, but
with different types themselves.
It seems like what you're proposing would require explicit
VIEW_CONVERT_EXPRs from k to some integral type, then a BIT_FIELD_REF
that extracts bits into the same type, and then some other conversion
to the type with the width and precision of the field type.
This is not just a lot of explicit conversion that might very well be
encoded in BIT_FIELD_REF by avoiding its now-redundant TREE_TYPE (not
necessarily a bad thing), but also a requirement for significantly
different code paths to handle the two cases, which AFAICT will both
lead to poorer optimization.
E.g., how do you envision generating code for foo() above? (The call
to bar() is there just to prevent the accesses to k from being
short-circuited, such that reads and writes are both clearly spelled
out).
FWIW, what we (could) do now is something along the lines of:
BIT_FIELD_REF(int) = x;
BIT_FIELD_REF(unsigned) = y;
bar();
T.1 = BIT_FIELD_REF(int);
T.2 = BIT_FIELD_REF(unsigned);
T.3 = (int)T.2;
T.4 = T.1 + T.3;
return T.4;
> (and not a bitfield type of the referenced size -- in which case the
> BIT_FIELD_REF_UNSIGNED would be useless)
There's no such thing as a language-independent bitfield type of the
referenced size. When you ask for an integral type with a certain bit
width, you may get a wider type, even with a wider precision. And
that's where BIT_FIELD_REF_UNSIGNED should come into play, although I
remember I had to deal with some inconsistencies in the handling of
this stuff while working on SRA.
> fold currently optimizes a.b.c == 0 to BIT_FIELD_REF & 1
> for bit field field-decls c. IMHO this is bad because it pessimizes
> TBAA (needs to use a's alias set, not the underlying integral type
> alias set) and it "breaks" type correctness as arbitrary structure
> types appear as operand zero.
I don't quite see how this breaks type correctness, can you elaborate?
I understand the problem about alias sets. Ideally, if we're
accessing part of an object with BIT_FIELD_REF, it would be useful to
narrow the alias set such that only the alias sets of the fields
present in words related with that region get a say in the aliasing
properties of this statement. For BIT_FIELD_REFs used only as inputs,
we could even do with the alias sets of fields that are within the
range [big-num,big-num + 8), but for those used as outputs, it seems
to me that we may need to bring in adjacent fields within the same
words to ensure correctness for MEM accesses after the BIT_FIELD_REF
write is broken down into read and write operations which may be
intermixed by schedule with other operations on the same words.
Makes sense?
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Constrain valid arguments to BIT_FIELD_REF
On Sat, 8 Mar 2008, Alexandre Oliva wrote: > On Mar 4, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > the type of the result is unspecified. > > ??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm > pretty sure that's what specifies the type of the result. You are late, the second patch installed that gets rid of BIT_FIELD_REF_UNSIGNED constrains it to be of the same "precision" of the extracted bitsize. > > I suggest to make sure that bit position and size are constants, > > +1 > > > the object referenced is of integral type > > This would break the use of SRA to extract sub-objects of non-integral > type. IIRC Ada does such things. No frontend generates BIT_FIELD_REF. But yes, SRA does with structures as base object. We don't yet enforce this, MEM_REF will enforce BIT_FIELD_REF operates on registers only. > > the result type is of the same type as the operand zero type > > Err, this doesn't make much sense to me. Consider: Right. By means of fixing the BIT_FIELD_REF_UNSIGNED case it is now as specified above. > It seems like what you're proposing would require explicit > VIEW_CONVERT_EXPRs from k to some integral type, then a BIT_FIELD_REF > that extracts bits into the same type, and then some other conversion > to the type with the width and precision of the field type. The least conversion is removed. You can look at the MEM_REF branch and see that the load from memory is done with a MEM_REF expression from the register result the bits are extracted with BIT_FIELD_REF. > This is not just a lot of explicit conversion that might very well be > encoded in BIT_FIELD_REF by avoiding its now-redundant TREE_TYPE (not > necessarily a bad thing), but also a requirement for significantly > different code paths to handle the two cases, which AFAICT will both > lead to poorer optimization. > > E.g., how do you envision generating code for foo() above? (The call > to bar() is there just to prevent the accesses to k from being > short-circuited, such that reads and writes are both clearly spelled > out). > > FWIW, what we (could) do now is something along the lines of: > > BIT_FIELD_REF(int) = x; > BIT_FIELD_REF(unsigned) = y; > bar(); > T.1 = BIT_FIELD_REF(int); > T.2 = BIT_FIELD_REF(unsigned); > T.3 = (int)T.2; > T.4 = T.1 + T.3; > return T.4; > > > (and not a bitfield type of the referenced size -- in which case the > > BIT_FIELD_REF_UNSIGNED would be useless) > > There's no such thing as a language-independent bitfield type of the > referenced size. When you ask for an integral type with a certain bit > width, you may get a wider type, even with a wider precision. And > that's where BIT_FIELD_REF_UNSIGNED should come into play, although I > remember I had to deal with some inconsistencies in the handling of > this stuff while working on SRA. > > > fold currently optimizes a.b.c == 0 to BIT_FIELD_REF & 1 > > for bit field field-decls c. IMHO this is bad because it pessimizes > > TBAA (needs to use a's alias set, not the underlying integral type > > alias set) and it "breaks" type correctness as arbitrary structure > > types appear as operand zero. > > I don't quite see how this breaks type correctness, can you elaborate? > > I understand the problem about alias sets. Ideally, if we're > accessing part of an object with BIT_FIELD_REF, it would be useful to > narrow the alias set such that only the alias sets of the fields > present in words related with that region get a say in the aliasing > properties of this statement. For BIT_FIELD_REFs used only as inputs, With MEM_REF this is done by explicitly tracking the alias-set used for the access in the MEM_REF expr. Richard.
Combine repeats matching on insn pairs and will ICE on 3.
Hi,
I have problem with data flow and combine that is causing ICE with
experimental build. Despite all efforts to blame my own target changes,
I have reached the conclusion that this is a gcc COMBINE bug, but seek
your advice before filing a bug report.
The problem seems to be that the LOG_LINKS that combine creates and uses
can include multiple references between instruction pairs.
The information is derived from DF. That will produce multiple
references to the same instructions if the register in question is a
hard register that decomposes into several smaller registers.
The RTL that triggered problem is:
(insn 45 42 46 4 920625-1.c:55 (set (reg:SI 22 r22 [ temp.24 ])
(mem:SI (reg/v/f:HI 71 [ alpha ]) [2 S4 A8])) 19 {*movsi} (nil))
(insn 46 45 47 4 920625-1.c:55 (set (reg:SI 18 r18)
(mem:SI (plus:HI (reg:HI 68 [ ivtmp.18 ])
(const_int 4 [0x4])) [2 S4 A8])) 19 {*movsi} (nil))
(insn 47 46 48 4 920625-1.c:55 (parallel [
(set (reg:SI 22 r22)
(mult:SI (reg:SI 22 r22)
(reg:SI 18 r18)))
(clobber (reg:HI 26 r26))
(clobber (reg:HI 30 r30))
]) 43 {*mulsi3_call} (expr_list:REG_DEAD (reg:SI 18 r18)
(expr_list:REG_UNUSED (reg:HI 30 r30)
(expr_list:REG_UNUSED (reg:HI 26 r26)
(nil)
This is call to library function, and the parameter for instruction 47
are hard registers for example SI:R22 - which is physically actually
R22,23,24 and 25.
DF marks all 4 in def/use chains (which seems entirely correct)
When DF information is transferred into LOG_LINKS we still have 4
references back to the definition in instructions 45 and 47. From gdb
this was:
(gdb) print uid_log_links[47]
$8 = (rtx) 0x7ff140d0
(gdb) pr
(insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 45
(insn_list:REG_DEP_TRUE 45
(insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 46
(insn_list:REG_DEP_TRUE 4
6 (insn_list:REG_DEP_TRUE 46 (insn_list:REG_DEP_TRUE 46 (nil)
These multiple references causes COMBINE to try the same combinations
multiple times (it thinks they are different instructions). Apart from
burning CPU time, this appears to have no obvious problem for
instruction pairs (i.e. 2 only)
However, when 3 are combined, we end up trying to combine i3=47 with
instruction i2=46 and instruction i1=46 (thats right two copies of 46).
Mostly this is ok - except when we get a new pattern for i2, and then
delete i1 - and not realizing that i2 is also deleted.
This ICE occured when it tried to copy the REG_DEAD notes back to the
source of R22 - instruction 46 - which, of course was no longer there!
I'm thinking that create_log_links, needs to distill the links down to
avoid duplicates, but I'm really not sure what to blame.
best regards
Andy
Re: Seg fault in call_gmon_start
Desineni, Harikishan wrote: I just compiled an app with GCC. It is segmentation faulting in call_gmon_start (even before reaching main() of my program Gcc usage questions should not be sent to the gcc list. This list is for being doing development work on gcc. This is an appropriate question for the gcc-help list. It will probably do nothing unless you compiled with -pg. The important bit here is that your program is apparently failing on the very first instruction it executes, as call_gmon_start is probably the first function in the init section, which contains initializers run before calling main. So there is apparently something seriously wrong with your setup, e.g. the kernel isn't constructing the process stack correctly, or the process stack is being mapped to non-existent memory, or something else unusual is going wrong. There may not be anything wrong with gcc itself. call_gmon_start comes from glibc by the way. Look there for more info. Jim
[tuples] gimple_assign_subcode for GIMPLE_SINGLE_RHS
Hi,
I just noticed an error in a part of the code that I converted, that
looks this way:
switch (gimple_assign_subcode (stmt))
{
case SSA_NAME:
handle_ssa_name ();
break;
case PLUS_EXPR:
handle_plus ();
break;
default:
something ();
}
The problem of course is that for GIMPLE_SINGLE_RHS, we do not maintain
the invariant that
gimple_assign_subcode (stmt) == TREE_CODE (gimple_assign_rhs1 (stmt)),
so gimple_assign_subcode typically will not be SSA_NAME, but VAR_DECL.
Enforcing this invariant might be hard and probably asking for more
trouble than it is worth. However, perhaps it would make sense
to use some special tree code to indicate GIMPLE_SINGLE_RHS, in order
to avoid confusion?
Zdenek
Re: gcc-4.1-20080303 is now available
On Mon, 3 Mar 2008, Gabriel Dos Reis wrote: > Do we still want to keep this branch alive? Looking at the changes that were made in the last three months still, it seems the branch is still surprisingly alive, so it may not yet be the time to close it. Personally I don't have a preference either way, but I'll update our main page to reflect the current status (no new releases, among others) a bit better and if the decision is to close it down volunteer to take the necessary steps. 2008-03-05 Kaveh R. Ghazi <[EMAIL PROTECTED]> Backport: 2007-09-27 Matthias Klose <[EMAIL PROTECTED]> * config/i386/t-linux64 (MULTILIB_OSDIRNAMES): Use ../lib32 as the multilib osdirname if it exists. * config/rs6000/t-linux64 (MULTILIB_OSDIRNAMES): Likewise. 2008-02-14 Alan Modra <[EMAIL PROTECTED]> PR target/34393 * config/rs6000/rs6000.md (restore_stack_block): Force operands[1] to a reg. 2008-02-09 John David Anglin <[EMAIL PROTECTED]> PR middle_end/34150 * pa.c (legitimize_pic_address): Add REG_EQUAL note on sets with a pic_label_operand source. Similarly, add a REG_LABEL note and update LABEL_NUSES during and after reload. 2008-02-08 Steven Bosscher <[EMAIL PROTECTED]> PR middle-end/34627 * combine.c (simplify_if_then_else): Make sure the comparison is against const0_rtx when simplifying to (abs x) or (neg (abs X)). 2008-02-04 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/33631 * expr.c (count_type_elements): Give for unions instead of guessing. 2008-02-01 Kaveh R. Ghazi <[EMAIL PROTECTED]> Backport: 2007-08-02 Nathan Froyd <[EMAIL PROTECTED]> PR middle-end/25445 * varasm.c (default_binds_local_p_1): Consult flag_whole_program if we are compiling with -fPIC. 2008-01-31 Richard Henderson <[EMAIL PROTECTED]> PR c/34993 * tree.c (build_type_attribute_qual_variant): Skip TYPE_DOMAIN for unbounded arrays. 2008-01-31 Andreas Krebbel <[EMAIL PROTECTED]> * config/s390/fixdfdi.h (__fixunstfdi, __fixtfdi): Rearrange the overflow check to make it easier to read. (__fixtfdi): Change the type of the ll member in union long_double to UDItype_x. 2008-01-24 Kaveh R. Ghazi <[EMAIL PROTECTED]> Backport: 2007-11-07 Kenneth Zadeck <[EMAIL PROTECTED]> PR middle-end/33826 * ipa-pure-const (static_execute): Added code to keep recursive functions from being marked as pure or const. * ipa-utils (searchc): Fixed comment. 2008-01-16 John David Anglin <[EMAIL PROTECTED]> PR libgfortran/34699 * pa-hpux.h (LINK_SPEC): Only search /lib/pa1.1 and /usr/lib/pa1.1 on static links. * pa-hpux10.h (LINK_SPEC): Likewise. * pa-hpux11.h (LINK_SPEC): Don't search /lib/pa1.1 and /usr/lib/pa1.1. 2008-01-14 Eric Botcazou <[EMAIL PROTECTED]> PR rtl-optimization/31944 * cse.c (remove_pseudo_from_table): New function. (merge_equiv_classes): Use above function to remove pseudo-registers. (invalidate): Likewise. 2007-12-31 John David Anglin <[EMAIL PROTECTED]> PR driver/33772 * collect2.c (SHLIB_SUFFIX): Define if not defined. (write_c_file_stat): Use SHLIB_SUFFIX. * som.h (SHLIB_SUFFIX): Define. * doc/tm.texi (SHLIB_SUFFIX): Document. 2007-12-20 Jakub Jelinek <[EMAIL PROTECTED]> PR bootstrap/34003 * c-decl.c (merge_decls): Copy RTL from olddecl to newdecl. * config/pa/pa.c (pa_encode_section_info): If !first, preserve SYMBOL_FLAG_REFERENCED flag. 2007-12-19 Kaz Kylheku <[EMAIL PROTECTED]> PR rtl-optimization/34456 * resource.c (mark_set_resources): Use regs_invalidated_by_call rather than call_used_regs and global_regs. Gerald
