[Bug tree-optimization/104475] [12/13/14 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

[aph at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475

Andrew Haley  changed:

   What|Removed |Added

 CC||aph at gcc dot gnu.org

--- Comment #27 from Andrew Haley  ---
Is this one still alive? It's still causing problems in the wild.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[aph at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522

--- Comment #23 from Andrew Haley  ---
This bug has pernicious effects in many more places:

https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html

Florian is right: at least, GCC should not automatically link crtfastmath.o
with -shared. Better, separate fiddling with the FP control register from
-ffast-math entirely.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #62 from Andrew Haley  ---
Just a bit of clarification:

(In reply to James Kuyper Jr. from comment #59)
> 
> > 1) all type-based alias analysis is effectively impossible
> 
> Alias analysis is only affected by the special guarantee if
> a) the types involved are both struct types

> b) both struct types are members of the same union
> c) the struct types share a common initial sequence

OK to all of those.

> d) the code in question inspects the value of one of the members of the
> common initial sequence.

While this is a reasonable inference from what the text of the
standard says, type-based alias analysis, by definition, does not pay
any attention to what any piece of code does.  The analysis is purely
type-based: that is to say, it only uses the types, and the only
question it answers is "Do these types alias?"

> e) a completed declaration of the union type that they are members
> of is visible at the point in the code where the inspection occurrs.

As explained elsewhere, TBAA doesn't use visibility as a criterion.

> It seems to me that the overwhelming majority of cases will fail to
> meet at least one of those requirements, so type-based alias
> analysis is still possible, it's just made more complicated by the
> need to check for those things.

That's not quite right, as explained above.  If you use information
other than types in alias analysis, it's no longer TBAA.  It is a
fundamental principle of TBAA that the result of an aliasing query
never changes for any pair of types.

We are extremely unlikely to redesign a big part of the optimizer for
this dusty corner case.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #60 from Andrew Haley  ---
(In reply to James Kuyper Jr. from comment #51)
> (In reply to Andrew Haley from comment #49)
> > (In reply to James Kuyper Jr. from comment #46)
> > 
> > The principle of type-based alias analysis is that all you know about
> > two types is their types, not the location of any code that uses them.
> > There are no scopes.  The oracle, given only the types, has to say
> > whether they alias or not, regardless of where those types are used in
> > a program.  The location isn't an input to the oracle.
> > 
> > Bear in mind that inlining and other kinds of code motion happen, and
> > code is often evaluated "outside" the scopes in which it was written
> > and in a completely different order.  That's all perfectly normal
> > optimization.
> > 
> > Besides, when the alias oracle is consulted, all that scope stuff has
> > gone.  It's only relevant to the front end.
> 
> I was only pointing out that implementing this special guarantee where it
> applies, and only where it applies, requires keeping information that must
> already have been collected. If the current design discards that information
> before performing the relevant optimizations, I can understand that this
> would require a significant re-design - but the re-design takes the form of
> saving information already collected, not of collecting additional
> information.

Well, yes, but this is all stuff we already know.  A total redesign of
alias analysis is not going to happen just for this rule.

> > > > So, if any union types with a common initial sequence are declared
> > > > anywhere in a program, then their member types alias.
> > > 
> > > As I understand it, the visibility rule was added specifically for
> > > the purpose of NOT requiring that the entire program be covered by
> > > this exception.
> > 
> > I don't think so.  As I read it, it was a way of declaring to the
> > compiler that they types are intended to alias.
>
> By "the visibility rule", I mean, very specifically, the phrase
> "anywhere that a declaration of the completed type of the union is
> visible". If the intent had been to disable aliasing throughout the
> entire program, that intent could have been expressed by simply
> removing those words entirely; if there was any doubt that people
> would understand the absence of those words correctly, then they
> could have been replaced with the phrase "anywhere, regardless of
> whether or not the completed type of the union was visible". I don't
> see any plausible reason for the committee to write "anywhere that a
> declaration of the completed type of the union is visible", unless
> that phrase was intended to restrict applicability of the special
> guarantee.

And in 1990s compiler technology it might well have been possible to
restrict the effect of this to a single function.  Back then it was
commonplace to parse a function, generate code, and then throw
everything except the code away.  But compiler technology has moved a
long way since then and it is inevitable that if we are to honour N685
we must coarsen the effect of the visibility of the union.

> > > Knowledgeable people writing code intended to take advantage of this
> > > feature of C are likely to carefully place completed declarations of
> > > the union's type so they disable those optimizations only where they
> > > need to be disabled, and to minimize the amount of code where this
> > > exception would unnecessarily disable useful optimizations.
> > 
> > Perhaps so, yes, but in practice it'd be pretty hard to do that.
> > Functions can only be defined in the other scope, and there's no way
> > to undefine a union type. 
> 
> True, but failing to define the union type is quite trivial. If I were
> writing code that used both struct types, but not the union type, and did
> nothing that relied upon the fact that they can alias each other, I would
> simply not #include the header that defines the completed union type,
> #including only the header that defines the struct types.

That'll be fine if you're only compiling a single translation unit at
a time.  If you're using link-time optimization, however, then the
effect of declaring structs in a union will inevitably result in those
structs being treated as aliases for the entire program being linked,
for the simple reason that the alias oracle always returns the same
answer when asked if two types are are aliases.  Therefore, if they're
aliases anywhere they must be aliases everywhere.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #57 from Andrew Haley  ---
(In reply to Davin McCall from comment #52)
> (In reply to Andrew Haley from comment #45)
> > (In reply to Davin McCall from comment #44)
> > > The "one special guarantee" clause appears in the section describing union
> > > member access via the "." or "->" operators, implying that it only applies
> > > to the access of union members via the union.
> > 
> > I don't believe that's what is intended, or that you can make such a
> > conclusion based on the section in which the rule appears.  It applies
> > to other accesses too, as is (somewhat) made clear by the rationale in
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm:
> 
> It certainly may not be what is intended by N685, but I think it's normally
> reasonable to conclude that a statement in a particular section of a
> document applies to that section and not more universally than that; in this
> case, the "universal" interpretation flatly contradicts the strict aliasing
> rule and any other rule which would otherwise disallow access, which seems
> extremely problematic to me.
> 
> In general it appears the committee have asserted that the "universal"
> interpretation (which since N685 requires visibility of the union
> declaration to be effective) is the correct one, but my argument

... doesn't really matter from a practical point of view, does it?
That ship has sailed.

> is that the actual text of the standard strongly implies something
> different, and that the interpretation being pushed instead turns
> another portion of the standard text into nonsense.

I don't think that's it really does, but I think we're done.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #50 from Andrew Haley  ---
(In reply to Andrew Haley from comment #49)
> 
> Perhaps so, yes, but in practice it'd be pretty hard to do that.
> Functions can only be defined in the other scope,

Should be "the outer scope"

> and there's no way
> to undefine a union type.  I guess you could be clever and put all of
> the functions which needed to know about the aliasing at the end of a
> translation unit.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #49 from Andrew Haley  ---
(In reply to James Kuyper Jr. from comment #46)
> (In reply to Andrew Haley from comment #42)
> ...
> > In order to use type-based alias analysis in any LTO framework it's
> > necessary to save type information, and this is just more type
> > information. ...
> 
> > ... The question is, I suppose, how to handle the scopes of
> > union declarations.  I'd just treat them as being global, which in
> > practice isn't unrealistic because such declarations are in header
> > files in global scope and shared anyway.
> 
> Why not use the actual scope of the completed union declaration,
> which is what the relevant rule refers to?

The principle of type-based alias analysis is that all you know about
two types is their types, not the location of any code that uses them.
There are no scopes.  The oracle, given only the types, has to say
whether they alias or not, regardless of where those types are used in
a program.  The location isn't an input to the oracle.

Bear in mind that inlining and other kinds of code motion happen, and
code is often evaluated "outside" the scopes in which it was written
and in a completely different order.  That's all perfectly normal
optimization.

Besides, when the alias oracle is consulted, all that scope stuff has
gone.  It's only relevant to the front end.  

> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their member types alias.
> 
> As I understand it, the visibility rule was added specifically for
> the purpose of NOT requiring that the entire program be covered by
> this exception.

I don't think so.  As I read it, it was a way of declaring to the
compiler that they types are intended to alias.

> Knowledgeable people writing code intended to take advantage of this
> feature of C are likely to carefully place completed declarations of
> the union's type so they disable those optimizations only where they
> need to be disabled, and to minimize the amount of code where this
> exception would unnecessarily disable useful optimizations.

Perhaps so, yes, but in practice it'd be pretty hard to do that.
Functions can only be defined in the other scope, and there's no way
to undefine a union type.  I guess you could be clever and put all of
the functions which needed to know about the aliasing at the end of a
translation unit.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #47 from Andrew Haley  ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Haley from comment #42)
> > 
> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their member types alias.  Alternatively,
> > a tighter implementation might restrict such declarations to a
> > compilation unit, in which case the alias oracle would scan only the
> > union types declared in that unit.
> 
> So for the middle-end the easiest thing would be if the FE would comply
> to its existing semantics and for the initial sequences generate a
> transparent struct.  Thus,
> 
> union {
>  struct A { int i; float f; double z; } a;
>  struct B { int i; float f; void *p; } b;
> };
> 
> would cause the FE to "implement" struct A and B like
> 
>  struct __init_seq1 { int i; float f; };
>  struct A { struct __init_seq1 _transp_memb1; double z; } a;
>  struct B { struct __init_seq1 _transp_memb2; void *p; } b;
> 
> then everything would work as expected from an aliasing point of view.
> The difficulty is probably that argument passing of A and B might
> change depending on how the ABIs are defined and how the backend handles
> those wrapping structs.

Nice.  I've got to admit that's a clever, idea, but it's also a very
big gotcha.

> But as you can clearly see the above would be also a way for the user
> to get what the clause permits without the clause being present.  So
> I'm not sure why this clause was added.

That's somewhat explained by N685, which does contain the rationale.
In short: proposal before N685 was to allow *every* pair of pointers
to structures with a common initial sequence to alias.  The revised
version (which was accepted) restricts this to structures with a
common initial sequence where a union of these structures is visible
to the compiler.

> language specifications have defects ...

Yabbut, N685 was accepted and the proposal does explain why.  Maybe it
shouldn't have been done that way, but it was done, and it was done
deliberately, as far as I can see.

> > > When I read the language text then a union declaration in between
> > > two accesses will change the semantic of the second?
> > 
> > Not necessarily.  It would be correct to collect all union
> > declarations at the end of parsing and then use those to feed the
> > alias oracle.  There's no actual need to restrict their scope.  Sure,
> > it would lead to GCC being somewhat over-cautious, but that's OK.
> 
> given the TBAA oracle is filled on-demand it is important that both
> outcomes are allowed. 

Okay, I don't get this.  Why not simply say that if a union type with
the initial common sequence exists anywhere, it is as though it were
declared at the start of every TU.

> I still don't see how we can make it work easily in the middle-end.

I don't think I ever said it would be easy!  I am saying, though, that
it's not the end of TBAA as we know it, but a refinement in which a
front end can feed into the alias oracle sets of types that are known
to alias.

You can think of it as a declaration:

__alias__ {
  type_a, type_b, type_c
};

which is an additional input to the oracle.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #45 from Andrew Haley  ---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
> 
> The "one special guarantee" clause appears in the section describing union
> member access via the "." or "->" operators, implying that it only applies
> to the access of union members via the union.

I don't believe that's what is intended, or that you can make such a
conclusion based on the section in which the rule appears.  It applies
to other accesses too, as is (somewhat) made clear by the rationale in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm:

The proposed solution is to require that a union declaration be visible
if aliases through a common initial sequence (like the above) are possible.
Therefore the following TU provides this kind of aliasing if desired:

union utag {
  struct tag1 { int m1; double d2; } st1;
  struct tag2 { int m1; char c2; } st2;
};

int similar_func(struct tag1 *pst2, struct tag2 *pst3) {
  pst2->m1 = 2;
  pst3->m1 = 0;   /* might be an alias for pst2->m1 */
  return pst2->m1;
}

I know this is non-normative and not even in the standard, but it does
explain what was intended.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #42 from Andrew Haley  ---
On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> 
> --- Comment #41 from rguenther at suse dot de  ---
> On April 29, 2018 1:51:58 PM GMT+02:00, "aph at gcc dot gnu.org"
> <gcc-bugzi...@gcc.gnu.org> wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>>
>> --- Comment #40 from Andrew Haley  ---
>> (In reply to rguent...@suse.de from comment #29)
>>
>>> Note I repeatedly said this part of the standard is just stupid.  It
>> makes
>>> most if not all type-based alias analysis useless.
>>
>> I don't think so.  It does mean that we'd have to feed all declared
>> union types (or, at least the ones containing structs with common
>> initial sequences) into the alias oracle.  While unpleasant, in that
>> simply declaring a type without even declaring an object of that type
>> changes code generation, it doesn't render all type-based alias
>> analysis useless.
> 
> How do you handle this within the LTO framework?

In order to use type-based alias analysis in any LTO framework it's
necessary to save type information, and this is just more type
information.  The question is, I suppose, how to handle the scopes of
union declarations.  I'd just treat them as being global, which in
practice isn't unrealistic because such declarations are in header
files in global scope and shared anyway.

So, if any union types with a common initial sequence are declared
anywhere in a program, then their member types alias.  Alternatively,
a tighter implementation might restrict such declarations to a
compilation unit, in which case the alias oracle would scan only the
union types declared in that unit.

>>> Which means I'll refuse any patches implementing it in a way that
>>> affects default behavior.
>>
>> Maybe --pedantic or even --pedantic-aliasing?
> 
> Whatever you call it I doubt any working solution will fit nicely
> into our existing TBAA framework.

Well, perhaps not, but this is the language specification.

> When I read the language text then a union declaration in between
> two accesses will change the semantic of the second?

Not necessarily.  It would be correct to collect all union
declarations at the end of parsing and then use those to feed the
alias oracle.  There's no actual need to restrict their scope.  Sure,
it would lead to GCC being somewhat over-cautious, but that's OK.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #40 from Andrew Haley  ---
(In reply to rguent...@suse.de from comment #29)

> Note I repeatedly said this part of the standard is just stupid.  It makes
> most if not all type-based alias analysis useless.

I don't think so.  It does mean that we'd have to feed all declared
union types (or, at least the ones containing structs with common
initial sequences) into the alias oracle.  While unpleasant, in that
simply declaring a type without even declaring an object of that type
changes code generation, it doesn't render all type-based alias
analysis useless.

> Which means I'll refuse any patches implementing it in a way that affects
> default behavior.

Maybe --pedantic or even --pedantic-aliasing?

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848

Andrew Haley  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||aph at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #35 from Andrew Haley  ---
Boehm GC is gone from GCC sources.

[Bug tree-optimization/79943] Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79943

Andrew Haley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andrew Haley  ---
Fixed.

[Bug tree-optimization/79943] Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79943

--- Comment #1 from Andrew Haley  ---
Author: aph
Date: Wed Mar  8 11:35:23 2017
New Revision: 245974

URL: https://gcc.gnu.org/viewcvs?rev=245974=gcc=rev
Log:
2017-03-08  Andrew Haley  

PR tree-optimization/79943
* tree-ssa-loop-split.c (compute_new_first_bound): When
calculating the new upper bound, (END-BEG) should be added, not
subtracted.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79943.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-split.c

[Bug tree-optimization/79943] New: Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79943

Bug ID: 79943
   Summary: Loop splitting breaks with loops of pointer type
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aph at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40914=edit
GCC test case,

If a loop index has POINTER_TYPE, splitting generates incorrect splits because
(end-beg) is incorrectly negated.  Patch to follow.

[Bug java/21855] array bounds checking elimination

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855

Andrew Haley  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #25 from Andrew Haley  ---
We'll never do this.

[Bug java/15525] suggestion to enable cast elimination

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15525

Andrew Haley  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Andrew Haley  ---
We'll never do this.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #16 from Andrew Haley aph at gcc dot gnu.org ---
(In reply to mwahab from comment #14)
 (In reply to Andrew Haley from comment #13)

  But LDAXR/STLXR doesn't do that, and there's no write barrier at all when
  the compare fails.  If the intention really is to map onto c++11, this
  specification is wrong.
 
 The LDAXR/STLXR sequences rely on the C11/C++11 prohibition of data races.
 That the __atomic builtins assume this restriction is implied by the
 references to C11/C++11 in the documentation but should probably be made
 clearer. I'll try to write a patch, if nobody else gets there first.

Right.

 I'll have to look at the compare-exchange code, it does looks like it goes
 wrong.

Well... goes wrong how?  If it's intended to be a C++11 sequentially-consistent
CAS, it's just fine.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #18 from Andrew Haley aph at gcc dot gnu.org ---
(In reply to mwahab from comment #17)

 
 int cas(int* barf, int* expected, int* desired)
 {
   return __atomic_compare_exchange_n(barf, expected, desired, 0,
__ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
 }
 
 cas:
   ldr w3, [x1]
 .L3:
   ldaxr   w4, [x0]
   cmp w4, w3
   bne .L4
   stlxr   w5, w2, [x0]  ; store-release
   cbnzw5, .L3
 .L4:
   csetw0, eq
   cbz w0, .L6
   ret
   .p2align 3
 .L6:
   str w4, [x1]  ; store, no barrier.
   ret
 
 
 This looks odd to me but I'd need look into it more.

That looks fine to me: if the CAS fails, the prev value - *expected.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #20 from Andrew Haley aph at gcc dot gnu.org ---
(In reply to mwahab from comment #19)
 (In reply to Andrew Haley from comment #18)
 
 It looks inconsistent with C11 S7.17.7.4-2 (C++11 S29.6.4-21) Further, if
 the comparison is true, memory is affected according to the value of
 success, and if the comparison is false, memory is affected according to the
 value of failure. (where success and failure are the memory model
 arguments.) In this case, the write to *exp should be memory_order_seq_cst.

But no store actually takes place, so the only effect is that of the read. You
can't have a sequentially consistent store without a store.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 CC||aph at gcc dot gnu.org

--- Comment #13 from Andrew Haley aph at gcc dot gnu.org ---
There's surely a documentation problem here.

GCC defines this:

`__ATOMIC_SEQ_CST'
 Full barrier in both directions and synchronizes with acquire
 loads and release stores in all threads.

But LDAXR/STLXR doesn't do that, and there's no write barrier at all when the
compare fails.  If the intention really is to map onto c++11, this
specification is wrong.

But if this specification is correct, then

bool gcc_cas() {
  int expected = 1;
  int desired = 2;
  return __atomic_compare_exchange(barf, expected, desired, false,
   __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}

gcc_cas():
subsp, sp, #16
movw1, 1
adrpx0, .LANCHOR0
strw1, [sp,12]
addx0, x0, :lo12:.LANCHOR0
movw2, 2
.L10:
ldaxrw3, [x0]
cmpw3, w1
bne.L11
stlxrw4, w2, [x0]
cbnzw4, .L10
.L11:
csetw0, eq
addsp, sp, 16
ret

is wrong.

[Bug java/64044] Java emits bogus .class$ decls

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044

--- Comment #5 from Andrew Haley aph at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #4)
 On Mon, 24 Nov 2014, aph at redhat dot com wrote:
 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044
  
  Andrew Haley aph at redhat dot com changed:
  
 What|Removed |Added
  
   CC||aph at redhat dot com
  
  --- Comment #2 from Andrew Haley aph at redhat dot com ---
  So, is the solution to this trivially not to mark the .class$ decls as
  TREE_CONST ?
 
 Yes, see the patch I proposed (in testing right now, I'll post it
 and ask for approval later today unless you want to pre-approve here)

Fine by me.  I did that because I wanted some way to tell GCC that it could
treat the field as readonly, but TREE_CONST doesn't do that.

[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-01
 CC||aph at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

--- Comment #11 from Andrew Haley aph at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #9)
 (In reply to Andrew Haley from comment #8)
  While it's true that we can play hardball on this one by insisting that only
  char arrays should be used with placement new, it wouldn't really do any
  good.  I don't think it would make any real-world code more efficient.
 
 On the contrary, this bug is an example of making real code more efficient,
 just inappropriately because of the special status of char arrays.  We
 really don't want to have to assume that any random object can invisibly
 change type, as that would make type-based optimizations pretty useless.

In this case?  Really?  What real well-defined code would be pessimized by
disabling this transformation in the case of POD types?

 As far as I know people always use char arrays for placement new anyway; at
 least all the examples I've ever seen do.

I'm not really sure how, given that objects must be aligned.  We don't really
know how much code this transformation breaks, but I do know that it breaks in
ways that are hard to diagnose: in the Java example a function silently falls
through to whatever happens to follow it.

How about a compromise?  Make this optimization respect -fno-strict-aliasing. 
People already expect that option to disable type-based optimizations.

[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

--- Comment #8 from Andrew Haley aph at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #7)
 (In reply to Jan Hubicka from comment #6)
  It is a bit
  questionable on how precisely define what type transitions are allowed by
  placement new.  This is quite conservative definition except for the
  requirement that type needs to be large enough to contain the newly built
  type.
 
 We don't need to handle all non-PODs; arrays of (unsigned) char are special
 under the aliasing rules, so that you can construct any type of object in a
 char array and access the object representation of any type via a char
 pointer.  You can't randomly change the object stored in a buffer of any
 other type.

While it's true that we can play hardball on this one by insisting that only
char arrays should be used with placement new, it wouldn't really do any good. 
I don't think it would make any real-world code more efficient.  It makes sense
to play safe by assuming that any object of a non-polymorphic type might be
overwritten by placement new.

[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

--- Comment #5 from Andrew Haley aph at gcc dot gnu.org ---
Jan, can we please have an ETA to fix this?  It is a very importantant problem
for Java because it breaks OpenJDK.

[Bug c++/60965] New: IPA: Devirtualization versus placement new

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

Bug ID: 60965
   Summary: IPA: Devirtualization versus placement new
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aph at gcc dot gnu.org

Created attachment 32683
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32683action=edit
Reproducer here:

Summary: Devirtualization uses type information to determine if a
virtual method is reachable from a call site.  If type information
indicates that it is not, devirt marks the site as unreachable.  I
think this is wrong, and it breaks some programs.

Consider this class:

class Container {
  void *buffer[5];
public:
  EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
  Container() { new (buffer) EmbeddedObject(); }
};

Placement new is used to embed an object in a buffer inside another
object.  Its address can be retrieved.  This usage of placement new is
common, and it even appears as the canonical use of placement new in
the in the C++ FAQ at
http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
this may not be strictly legal.  For one thing, the memory at buffer
may not be suitably aligned.  Please bear with me.)

The embedded object is an instance of:

class EmbeddedObject {
public:
  virtual int val() { return 2; }
};

And it is called like this:

extern Container o;
int main() {

  cout  o.obj()-val()  endl;
}

The devirtualization pass looks into the call to val() and the type of
o, decides that there is no type inside o that is compatible with
EmbeddedObject, and inserts a call to __builtin_unreachanble().  As a
result, instead of printing 2, the program does nothing.

[Bug ipa/60963] [4.10 Regression] wrong devirt with placement new

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60963

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||aph at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Haley aph at gcc dot gnu.org ---
I'm closing this because it's a dupe.

*** This bug has been marked as a duplicate of bug 60965 ***

[Bug ipa/60965] IPA: Devirtualization versus placement new

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #1 from Andrew Haley aph at gcc dot gnu.org ---
*** Bug 60963 has been marked as a duplicate of this bug. ***

[Bug java/60667] Undefined behavior in Java FE

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60667

--- Comment #4 from Andrew Haley aph at gcc dot gnu.org ---
Still no luck with ubsan, which seems to be broken:

/usr/local/i686-pc-linux-gnu/sys-include-O2  -g -O2 -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic
-mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector 
-shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
-Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o
_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o
_multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o
_bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o
_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o
_fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o
_floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o
_udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o
tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o
letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o
trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o
unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o
libgcc.a -lc  rm -f ./libgcc_s.so  if [ -f ./libgcc_s.so.1 ]; then mv -f
./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi  mv ./libgcc_s.so.1.tmp
./libgcc_s.so.1  ln -s libgcc_s.so.1 ./libgcc_s.so
/usr/bin/ld: /gcc/obj-i686-pc-linux-gnu/./gcc/liblto_plugin.so: error loading
plugin: /gcc/obj-i686-pc-linux-gnu/./gcc/liblto_plugin.so: undefined symbol:
__ubsan_handle_type_mismatch
collect2: error: ld returned 1 exit status
make[3]: *** [libgcc_s.so] Error 1
make[3]: Leaving directory
`/gcc/obj-i686-pc-linux-gnu/i686-pc-linux-gnu/libgcc'
make[2]: *** [all-stage2-target-libgcc] Error 2
make[2]: Leaving directory `/gcc/obj-i686-pc-linux-gnu'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/gcc/obj-i686-pc-linux-gnu'
make: *** [all] Error 2

If you can tell me how you do a build I'll be grateful.

[Bug java/60667] Undefined behavior in Java FE

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60667

--- Comment #6 from Andrew Haley aph at gcc dot gnu.org ---
OK, pls ping me whan the tree is stable and I'll fix the Java FE.

[Bug java/55764] [4.8/4.9 Regression] ICE when building frysk

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Andrew Haley aph at gcc dot gnu.org ---
This is a WONTFIX.

[Bug java/55764] [4.8/4.9 Regression] ICE when building frysk

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

[Bug libgcj/55716] [4.8 Regression] gjavah throws an exception

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55716



--- Comment #5 from Andrew Haley aph at gcc dot gnu.org 2012-12-18 10:00:29 
UTC ---

Author: aph

Date: Tue Dec 18 10:00:18 2012

New Revision: 194574



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194574

Log:

PR gcc/55716  [4.8 Regression] gjavah throws an exception



Modified:

trunk/libjava/classpath/ChangeLog

[Bug libgcj/55716] [4.8 Regression] gjavah throws an exception

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55716



Andrew Haley aph at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #6 from Andrew Haley aph at gcc dot gnu.org 2012-12-18 10:01:39 
UTC ---

A comment must go here, apparently.

[Bug c/52936] New: Assertion failure in c-typeck.c

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52936

 Bug #: 52936
   Summary: Assertion failure in c-typeck.c
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gcc.gnu.org


Compile the attachment with trunk, and:

/home/aph/gcc/trunk/obj-x86_64-unknown-linux-gnu/gcc/cc1 signals.i -quiet
-mtune=generic -march=x86-64 -auxbase signals -O2

signals.c: In function 'segv_handler':
signals.c:219:3: internal compiler error: in pointer_diff, at c-typeck.c:3450
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

[Bug c/52936] Assertion failure in c-typeck.c

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52936

--- Comment #1 from Andrew Haley aph at gcc dot gnu.org 2012-04-11 16:06:08 
UTC ---
Created attachment 27134
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27134
Test case

[Bug tree-optimization/21855] array bounds checking elimination

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 Resolution|INVALID |

--- Comment #14 from Andrew Haley aph at gcc dot gnu.org 2012-01-10 15:52:07 
UTC ---
(In reply to comment #13)
 We can't optimize this because System.out.println can change args[].

That's the whole point: System.out.println cannot change args[], which is a
java array, and the length of a Java array is constant.  It is not an invalid
test case.

[Bug java/21855] array bounds checking elimination

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855

--- Comment #16 from Andrew Haley aph at gcc dot gnu.org 2012-01-10 16:26:51 
UTC ---
(In reply to comment #15)
 (In reply to comment #14)
  (In reply to comment #13)
   We can't optimize this because System.out.println can change args[].
  
  That's the whole point: System.out.println cannot change args[], which is a
  java array, and the length of a Java array is constant.  It is not an 
  invalid
  test case.
 
 I suppose
 
   public static void main(String[] args)
 
 is passing args by value (but the implementation detail uses reference
 passing for efficiency?).

args is indeed a reference to a Java array.  The length field of a Java
array is immutable.  The elements of an array are not immutable.

 In this case the Java frontend should do
 like the C++ frontend and tell this to the middle-end by properly
 marking args as 1) DECL_BY_REFERENCE, 2) use a TYPE_RESTRICT qualified
 pointer for the reference.  Then we would optimize this case.

If we could mark the length field as immutable that would fix it.  Is there any
way to do that?

[Bug java/21855] array bounds checking elimination

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855

--- Comment #19 from Andrew Haley aph at gcc dot gnu.org 2012-01-10 16:44:16 
UTC ---
(In reply to comment #17)
 (In reply to comment #16)
  (In reply to comment #15)
   (In reply to comment #14)
(In reply to comment #13)
 We can't optimize this because System.out.println can change args[].

That's the whole point: System.out.println cannot change args[], which 
is a
java array, and the length of a Java array is constant.  It is not an 
invalid
test case.
   
   I suppose
   
 public static void main(String[] args)
   
   is passing args by value (but the implementation detail uses reference
   passing for efficiency?).
  
  args is indeed a reference to a Java array.  The length field of a Java
  array is immutable.  The elements of an array are not immutable.
 
 You mean that System.out.println could change the elements of the array
 (well, it doesn't, but theoretically it could)?

In theory yes, it could.

   In this case the Java frontend should do
   like the C++ frontend and tell this to the middle-end by properly
   marking args as 1) DECL_BY_REFERENCE, 2) use a TYPE_RESTRICT qualified
   pointer for the reference.  Then we would optimize this case.
  
  If we could mark the length field as immutable that would fix it.  Is there 
  any
  way to do that?
 
 No.  What you can do is, via the method I outlined, tell GCC that
 args is to be treated similar to a local automatic variable - thus
 it cannot be refered to from other functions (unless you pass them
 its address of course).

But that doesn't help.  args *can* potentially be referred to by other
functions.  The special property we need to make use of its that fact that once
an array is created, its length can never change.

[Bug java/21855] array bounds checking elimination

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855

--- Comment #22 from Andrew Haley aph at gcc dot gnu.org 2012-01-10 17:08:30 
UTC ---
(In reply to comment #21)
 The Java frontend could handle this by performing loads of the length field
 via a SAVE_EXPR and sharing this across a function.  That way CSE would
 happen automagically.

Now that's a nice idea.  

In this specific case it should be easy, because array.length is used in the
control expression for the loop.  So. we can create the SAVE_EXPR when the loop
is initialized.

The problem with doing this in general is that we don't have a CFG, so we don't
always know when to create that SAVE_EXPR.  If we can find an initial use of an
array that dominates all other uses we can create the SAVE_EXPR at that point.

[Bug target/37651] __sync_bool_compare_and_swap creates wrong code with -fPIC

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37651

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||aph at gcc dot gnu.org
 Resolution||WORKSFORME

--- Comment #3 from Andrew Haley aph at gcc dot gnu.org 2012-01-06 10:17:52 
UTC ---
Reproducible with with 4.2.4 but not with 4.4.6 or 4.6.2 or HEAD.

[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888

--- Comment #8 from Andrew Haley aph at gcc dot gnu.org 2011-11-22 17:55:51 
UTC ---
(In reply to comment #7)

 isspace is actually marked as not throwing, i.e. throw() in C++.  In glibc
 2.15+ it happens to be implemented as throw() inline function which calls
 another function (which is throw() too), the problem is that with
 -fnon-call-exceptions the compiler doesn't know the function pointer is always
 non-NULL and assumes the call instruction might throw on SIGSEGV/SIGILL etc. 
 That will always work, but the compiler must assume it doesn't always, thus it
 needs -lsupc++ support with which libjava is not linked.

Thank you, all is now clear.  I wonder if it might make sense to fix this
in a more general way than simply not calling isspace().  Perhaps we could
provide a weak __cxa_call_unexpected, or find some way of persuading g++ not
to emit such a call.

[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888

--- Comment #6 from Andrew Haley aph at gcc dot gnu.org 2011-11-21 18:02:29 
UTC ---
I suppose I don't really object to a workaround in libjava, but surely the
sensible thing to do is fix isspace() not to throw.  It can't, anyway: that
would be in breach of its spec.

[Bug c/50773] float values are printed with greater precision than the float data type has when given as an argument to printf()

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50773

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 CC||aph at gcc dot gnu.org

--- Comment #2 from Andrew Haley aph at gcc dot gnu.org 2011-10-18 10:20:40 
UTC ---
This is definitely a C front-end bug.  If you look at the gimple dump, you can
see that the literal 268517138.f isn't being correctly truncated, but instead
the constant 2.68517138e+8 is being used instead:

main (int argc, char * * argv)
{
  double D.2549;
  const char * restrict D.2550;
  double D.2551;
  const char * restrict D.2552;
  int D.2553;
  float a;

  a = 2.68517152e+8;
  D.2549 = (double) a;
  D.2550 = (const char * restrict)  268517138.f = %f\t%f\n[0];
  printf (D.2550, 2.68517138e+8, D.2549);

C++ FE does it correctly:

int main(int, char**) (int argc, char * * argv)
{
  double D.2226;
  double D.2227;
  double D.2228;
  double D.2229;
  int D.2230;

  {
float a;

a = 2.68517152e+8;
D.2226 = (double) a;
D.2227 = (double) 2.68517152e+8;
printf ( 268517138.f = %f\t%f\n[0], D.2227, D.2226);

[Bug c/46926] Paired sin() cos() calls optimized to sincos() call.

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.02 17:19:22
 CC||aph at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug driver/46563] link with -lgcc when creating a shared lib

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #11 from Andrew Haley aph at gcc dot gnu.org 2010-11-22 09:47:52 
UTC ---
You see how hard it is to help people with problems like this: we just don't
know what weird things they may be doing that we don't know about!

I's a script because otherwise we'd have to find everywhere -lgcc_s was used
and replace it with -lgcc_s -lgcc.  It's simpler just to fix it in one place.

[Bug driver/46563] link with -lgcc when creating a shared lib

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563

--- Comment #13 from Andrew Haley aph at gcc dot gnu.org 2010-11-22 10:12:04 
UTC ---
Sure, but not everyone uses the driver, some use ld directly.

I might as well ask: why not?  libc is linked this way on GNU/Linux systems
too.  It's easy and convenient.

I don't know why C and C++ are treated differently.  I suspect it's just a
historical accident, but it doesn't matter because it doesn't break anything.

[Bug driver/46563] link with -lgcc when creating a shared lib

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563

--- Comment #2 from Andrew Haley aph at gcc dot gnu.org 2010-11-19 16:09:00 
UTC ---
If you try linking with -lgcc_s -lgcc, does everything then work?

[Bug driver/46563] link with -lgcc when creating a shared lib

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563

--- Comment #6 from Andrew Haley aph at gcc dot gnu.org 2010-11-19 17:30:35 
UTC ---
I am cross-compiling too.

Try this:

 $ cat /home/aph/x-arm/install/arm-linux-gnueabi/lib/libgcc_s.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library.  */
GROUP ( libgcc_s.so.1 libgcc.a )

[Bug java/45773] gcj fails to compile java

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45773

--- Comment #20 from Andrew Haley aph at gcc dot gnu.org 2010-09-28 09:54:30 
UTC ---
Author: aph
Date: Tue Sep 28 09:54:27 2010
New Revision: 164679

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164679
Log:
2010-09-27  Andrew Haley  a...@redhat.com

PR java/45773
* jvgenmain.c (main): Fix arg processing.


Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/jvgenmain.c

[Bug java/45773] gcj fails to compile java

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45773

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #21 from Andrew Haley aph at gcc dot gnu.org 2010-09-28 14:03:25 
UTC ---
.

[Bug java/40816] error: 'jvariant::jvariant(jbyte)' cannot be overloaded

[aph at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40816

Andrew Haley aph at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Andrew Haley aph at gcc dot gnu.org 2010-09-28 14:05:59 
UTC ---
.