http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55105
--- Comment #1 from Michael Haubenwallner 2012-10-30 07:58:20 UTC ---
Feels like a dup of bug#52623, or vice-versa.
Haven't tried --disable-build-poststage1-with-cxx recently, not sure if this
still should work with current trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #14 from Michael Haubenwallner 2012-08-30 07:33:16 UTC ---
Indeed, the old buffer is freed before being copied.
Yep, this isn't a regression. In fact, with 4.4.3 it was the /empty string/
having the size of 1 in the comment#0 testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #8 from Michael Haubenwallner 2012-08-29 15:20:50 UTC ---
Actually, valgrind does show an "Invalid write of size 1" for this testcase,
unrelated to the default string at all:
{
std::string s1 = "a";
s1.assign(s1.c_str(), 2);
}
So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #4 from Michael Haubenwallner 2012-08-29 10:50:22 UTC ---
(In reply to comment #0)
Extending the testcase shows even more bad behavior in 4.4.3 and earlier:
#include
#include
int main()
{
std::string s1, s2;
s1.assign(s2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #37 from Michael Haubenwallner 2012-04-16 13:29:06 UTC ---
A few more references:
The fix for this one issue is:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134
But this introduces /usr/ccs/bin/as coredump during gcc boots
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #17 from Michael Haubenwallner 2012-03-28 14:20:52 UTC ---
(In reply to comment #16)
> Symbolic linking or hard linking libNAME.so.1 to libNAME.so doesn't work? I
> seem to remember something strange about the way AIX loader followed s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #15 from Michael Haubenwallner 2012-03-28 08:21:37 UTC ---
(In reply to comment #14)
> > Do you see any technical issue why Import
> > Files cannot be used this way for filename-based versioning over the
> > traditional onefile-membern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #13 from Michael Haubenwallner 2012-03-23 16:39:53 UTC ---
Hmm, err, A and B aren't created at the same time by libtool.
Instead, this table really should include static-only libs too:
(S)tatic: libNAME.a(static.o)
(A)ix:libNAME.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #12 from Michael Haubenwallner 2012-03-23 10:29:15 UTC ---
(In reply to comment #11)
> Give package managers another choice how to build the packages, out of:
> A: libNAME.a(libNAME.so.1) (libtool default)
> B: libNAME.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #11 from Michael Haubenwallner 2012-03-23 09:31:41 UTC ---
Unless IBM does, I don't want to change any default here, nor force anyone to
use -brtl.
What I'm after is:
Give package managers another choice how to build the packages, out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #8 from Michael Haubenwallner 2012-03-22 20:33:01 UTC ---
I'm still grafting some RFC for gcc-ml with more background info for the
not-so-experienced ones, however I don't mind to discuss that here - eventually
resulting in a better RF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #6 from Michael Haubenwallner 2012-03-22 09:10:29 UTC ---
Traditionally, yes.
However, there are Import Files:
They can definitively help for the versioning issue,
and can probably help for the multilib issue too.
However, they canno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #4 from Michael Haubenwallner 2012-03-21 14:27:06 UTC ---
(In reply to comment #3)
> But the problem isn't with libquadmath itself, but with config-ml.in setting
> LD_LIBRARY_PATH to find the multilib-wise libstdc++.a, and (interesting
||salomon dot at
--- Comment #9 from Michael Haubenwallner 2012-03-21 14:20:42 UTC ---
Do you have most recent TechLevel and/or ServicePack installed?
AIX 6.1 is known to break with any ServicePack since 2011 calendarweek 12
(1112) and before 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #3 from Michael Haubenwallner 2012-03-21 09:38:00 UTC ---
(In reply to comment #2)
> We should disable libquadmath on AIX. It is not needed or useful there.
>
> Have you tried adding --disable-libquadmath when configuring GCC?
For -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #1 from Michael Haubenwallner 2012-03-19 17:20:23 UTC ---
Created attachment 26924
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26924
powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
Bug #: 52623
Summary: 4.7.0-RC-20120314: bootstrap failure on AIX due to
multilib and using C++ in post-stage1
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46887
--- Comment #9 from Michael Haubenwallner 2011-12-12 16:17:48 UTC ---
(In reply to comment #5)
> The problem still exists, but classpath is maintained upstream, not by GCC.
Checking out the GNU classpath project from savannah (CVS HEAD), there is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47591
--- Comment #2 from Michael Haubenwallner 2011-09-09 15:32:53 UTC ---
Created attachment 25235
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25235
output of 'gmake install' for gcc-4.6.1, using xlc v6 on aix5.3
Same here, however with gcc-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481
--- Comment #2 from Michael Haubenwallner 2011-07-06 11:26:37 UTC ---
Seems this is fixed since gcc-4.6.0 by
http://gcc.gnu.org/viewcvs?view=revision&revision=169981.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #26 from Michael Haubenwallner 2011-05-17 14:52:36 UTC ---
(In reply to comment #25)
> The fixed assembler is available as an efix for customers who ask.
We did do this here, but the efix'ed assembler just dumps core upon some C++
con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #31 from Michael Haubenwallner 2011-05-17 07:17:57 UTC ---
(In reply to comment #29)
> I'm now running AIX 6.1, oslevel -s returns 6100-06-03-1048 and the
> problem seems to persist with newer versions of gcc as well. I installed
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #21 from Michael Haubenwallner 2011-04-08 07:53:44 UTC ---
(In reply to comment #20)
> mean? Does this mean IBM consider it a GCC bug? I don't find the explanations
> on the page too useful.
The notification for this APAR also contai
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #18 from Michael Haubenwallner 2011-04-07 07:59:00 UTC ---
(In reply to comment #15)
> ld: 0711-596 SEVERE ERROR: Object expand.o
> An RLD for section 2 (.data) refers to symbol 852,
> but the storage class of the symbo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #28 from Michael Haubenwallner 2011-04-01 12:24:32 UTC ---
Looks like IBM "fixed" their Assembler to ignore invalid .line pseudo-ops
again:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #11 from Michael Haubenwallner 2011-03-23 07:46:49 UTC ---
(In reply to comment #10)
> IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves
> a new issue. The new error looks like:
Perry, have you seen this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #25 from Michael Haubenwallner 2011-02-25 09:53:57 UTC ---
Ohw, and then there is bug#47032 (caused by bug#46481) you might stumble upon
in libgfortran.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #24 from Michael Haubenwallner 2011-02-25 09:49:30 UTC ---
(In reply to comment #23)
> Using your suggestion for gmake bootstrap STAGE1_FLAGS=-0 gets me much
> further in the build. The problem has moved to building libgomp, and the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #20 from Michael Haubenwallner 2011-02-24 20:42:46 UTC ---
(In reply to comment #19)
> > /usr/bin/gcc -c -g -fkeep-inline-functions -DIN_GCC ...
>
> This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling.
(In rep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #6 from Michael Haubenwallner 2011-02-09 09:03:05 UTC ---
(In reply to comment #5)
> Created attachment 23120 [details]
> Patch to simply not use bss section with .bs, but private-data-section instead
>
> I'm going to try this patch w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47032
--- Comment #11 from Michael Haubenwallner 2011-02-08 22:14:19 UTC ---
(In reply to comment #10)
> #including math.h and then trying a link test
> should give correct results because it will fail to find __copysignl128 in
> libm
While this is ab
||salomon dot at
--- Comment #6 from Michael Haubenwallner 2011-01-25 19:56:14 UTC ---
This looks like a dupe of bug#46481.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #5 from Michael Haubenwallner 2011-01-25 15:40:07 UTC ---
Created attachment 23120
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120
Patch to simply not use bss section with .bs, but private-data-section instead
I'm going to t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #4 from Michael Haubenwallner 2011-01-25 12:52:22 UTC ---
What exactly is the difference for gcc between not initializing a static
variable and initializing it to zero?
This is the difference in the generated assembler file:
$ cat
||salomon dot at
--- Comment #3 from Michael Haubenwallner 2011-01-25 08:29:49 UTC ---
Same here with gcc-4.2.4 on AIX5.3 after upgrading from TL10 to TL12.
(need to figure out the exact details of the problem myself yet)
Which information is necessary here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46887
--- Comment #2 from Michael Haubenwallner 2010-12-13 22:18:57 UTC ---
It did hit me in gcc-4.2.4 (languages=c,c++) in Gentoo Prefix on AIX, where I
do have some automagic patches to enable runtime linking by default as well as
full "soname" suppor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #14 from Michael Haubenwallner 2010-12-13 12:46:25 UTC ---
(In reply to comment #9)
> Is the 64K limit really new? Is this really a change in AIX as or did
> something else change and start generating files referencing line numbers
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46887
Summary: Invalid AIX linker flag '-bnoerok', it has to be
'-bernotok'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
Michael Haubenwallner changed:
What|Removed |Added
Attachment #22538|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #10 from Michael Haubenwallner 2010-11-30 12:22:43 UTC ---
(In reply to comment #9)
> I believe the line number field in XCOFF is defined in
> /usr/include/linenum.h.
> According to that file, in 32 bit mode, line numbers are represe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #6 from Michael Haubenwallner 2010-11-29 09:05:53 UTC ---
I'm in contact with IBM vi a customer's support channel - initially for another
problem, and have added this 64k-line-limit recently.
Although no reply yet, I'll add updates her
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481
Michael Haubenwallner changed:
What|Removed |Added
Target||powerpc-ibm-aix6.1.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #4 from Michael Haubenwallner 2010-11-26 13:54:41 UTC ---
Created attachment 22538
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22538
Workaround to emit .line values >0 and <64k only
For now, I'm using this patch to get the deb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #3 from Michael Haubenwallner 2010-11-25 12:30:37 UTC ---
Huh - AIX-as also doesn't accept line numbers >=65536 any more since
SP6100-04-07-1036 it seems, as I get an error on ".line 118674" from
insn-automata.c later in bootstrap of g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
Michael Haubenwallner changed:
What|Removed |Added
Target||powerpc-ibm-aix6.1.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
Summary: AIX6.1 native assembler requires '.line' numbers
greater than zero
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
||salomon dot at
--- Comment #2 from Michael Haubenwallner 2010-11-24 16:34:48 UTC ---
dup of bug#33637
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481
Summary: long double should default to 64bit even for aix6.1
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedT
48 matches
Mail list logo
