--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-30 06:07 ---
int const*
Is legal C++, as it means a pointer to int const (which is the same as const
int), the qualifier can appear before after the type specifier.
(void) (q = (const int *) &i) >>>// const re-ordered
Be
--- Comment #2 from armin76 at gentoo dot org 2009-09-30 05:34 ---
(In reply to comment #1)
> I just rebuilt a vanilla gcc-4.4.1 with itself on armv5tel-linux-gnueabi, and
> as usual there were no problems. I even used your LDFLAGS=-Wl,-O1 and
> STAGE1_CFLAGS=-O settings.
>
Weird, guess
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-30 03:40 ---
Switching to c++ as I suggested initially, there were changes to the handling
of vague linkage and global declarations within the same period, and as I
mentioned nothing that seemed relevant in the backend.
--
dave
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-30 03:33 ---
Created an attachment (id=18670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18670&action=view)
same testcase compiled with gcc 4.3.4
Note the differences in the "-export: " directives in the .drectve section
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-30 03:32 ---
Created an attachment (id=18669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18669&action=view)
testcase source compiled by gcc HEAD
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-30 03:28 ---
Hi John,
What kind of TLS do you have on your platform? Also, does reverting the patch
help you any, or do you just end up with the failures that were showing in bug
41357?
That PR is still open because the fix didn
These new FAILs have been appearing on trunk since some time between 20090820
and 20090903:
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D12vfEv
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D22vfEv
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK3MI12vfE
--- Comment #2 from hxdg21 at yahoo dot com 2009-09-30 03:09 ---
Thank you for the clarification. My friend and I ran across this while
comparing the assembly generated by different compilers/platforms when
manipulating strings. A largely academic exercise. That piece of code did not
loo
--- Comment #1 from danglin at gcc dot gnu dot org 2009-09-30 02:55 ---
Introduced by revision 151959. I believe this comes from team.c.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #33 from amodra at bigpond dot net dot au 2009-09-30 02:29
---
To save people looking through the binutils bug report, here's the bug
analysis:
"You are using the old-style plt and got rather than the new secure plt (forced
by old startup files even if all the other code is
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-09-30 02:00 ---
It seems that the difference occurs at combine pass. With -g,
two insns
(insn 104 102 106 12 xxx.c:127 (set (reg:SI 207 [ stmt_4->gsbase.code ])
(zero_extend:SI (reg:QI 219 [ stmt_4->gsbase.code ]))) 156
{*
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-09-30 01:58 ---
Created an attachment (id=18668)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18668&action=view)
A reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41511
This may be a generic problem, though it's found on SH.
sh4-unknown-linux-gnu fails to bootstrap for a while with:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/cfgexpand.o differs
gcc/omp-low.o differs
The stage2 cfgexpand.o is compiled with -g -
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-09-30 01:48 ---
Created an attachment (id=18667)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18667&action=view)
c++0x test for std::complex
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41510
Here is a sketch of what C++0x std::complex might look like. Minus, of course,
constexpr. Also included in the patch is a testfile that does the usual
init_list tests on std::complex overloads.
It fails to compile, with ambiguous overloads. As so:
%$bld/H-x86-gcc.20090927/bin/g++ -std=gnu++0x -g
--- Comment #1 from mikpe at it dot uu dot se 2009-09-30 01:27 ---
I just rebuilt a vanilla gcc-4.4.1 with itself on armv5tel-linux-gnueabi, and
as usual there were no problems. I even used your LDFLAGS=-Wl,-O1 and
STAGE1_CFLAGS=-O settings.
A few notes:
- you seem to be building in the
--- Comment #13 from rwild at gcc dot gnu dot org 2009-09-30 00:44 ---
Fixed on trunk.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
### T++ ##
#!/bin/bash
#export COMPILER_PATH=/usr/local/dest/gcc/libexec/gcc/i686-pc-linux-gnu/4.5.0
/usr/local/dest/gcc/bin/g++ -v -c -fdump-tree-original $*
## t.cc ##
int main(int, char*[])
{
int i = 2;
const int *p = &i;
int const* q = &i; // legal C++ ???
int *
--- Comment #12 from rwild at gcc dot gnu dot org 2009-09-30 00:43 ---
Subject: Bug 38923
Author: rwild
Date: Wed Sep 30 00:43:28 2009
New Revision: 152315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152315
Log:
sed and head portability fixes in ld version check.
libstdc++-v
--- Comment #5 from rth at gcc dot gnu dot org 2009-09-29 23:43 ---
Yeah, that looks right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
--- Comment #5 from danglin at gcc dot gnu dot org 2009-09-29 23:10 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #4 from danglin at gcc dot gnu dot org 2009-09-29 23:05 ---
Subject: Bug 41393
Author: danglin
Date: Tue Sep 29 23:04:46 2009
New Revision: 152309
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152309
Log:
PR target/41393
* pa.c (hppa_profile_hook): U
--- Comment #5 from debian-gcc at lists dot debian dot org 2009-09-29
22:48 ---
fixed
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #4 from debian-gcc at lists dot debian dot org 2009-09-29
22:47 ---
sorry, the last comment should have gone to PR33263, I'll need to find the time
to recheck this issue.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
--- Comment #11 from debian-gcc at lists dot debian dot org 2009-09-29
22:45 ---
confirmed:
https://buildd.debian.org/fetch.cgi?&pkg=gcc-snapshot&ver=20090923-1&arch=alpha&stamp=1253933048&file=log
https://buildd.debian.org/fetch.cgi?&pkg=gcj-4.4&ver=4.4.1-4&arch=alpha&stamp=1252769258
--- Comment #3 from debian-gcc at lists dot debian dot org 2009-09-29
22:44 ---
confirmed:
https://buildd.debian.org/fetch.cgi?&pkg=gcc-snapshot&ver=20090923-1&arch=alpha&stamp=1253933048&file=log
https://buildd.debian.org/fetch.cgi?&pkg=gcj-4.4&ver=4.4.1-4&arch=alpha&stamp=1252769258&
--- Comment #4 from sje at cup dot hp dot com 2009-09-29 22:36 ---
Fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from sje at gcc dot gnu dot org 2009-09-29 22:21 ---
Subject: Bug 41365
Author: sje
Date: Tue Sep 29 22:21:27 2009
New Revision: 152306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152306
Log:
2009-09-29 Steve Ellcey
Alexander Monakov
P
--- Comment #3 from ubizjak at gmail dot com 2009-09-29 22:12 ---
4.2.4 is not supported anymore. Please try with newer gcc.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #10 from ubizjak at gmail dot com 2009-09-29 22:06 ---
Libjava has zero failures with gcc 4.3.5, 4.4.2 and 4.5.0 for me on latest
Gentoo. Please reopen if it still fails for you.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2009-09-29 22:02 ---
Please try with newer gcc, 4.2.x is not supported anymore.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from ubizjak at gmail dot com 2009-09-29 21:58 ---
(In reply to comment #0)
> libstdc++ test 23_containers/vector/cons/4.cc fails:
No more [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00242.html
--
ubizjak at gmail dot com changed:
What|R
--- Comment #4 from law at redhat dot com 2009-09-29 21:55 ---
Subject: Re: GCC choosing poor code sequence for certain
stores (x86)
On 09/29/09 15:18, rth at gcc dot gnu dot org wrote:
> --- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 ---
> There are already
--- Comment #2 from ubizjak at gmail dot com 2009-09-29 21:55 ---
(In reply to comment #1)
> Also the date here is from before the big gcj-eclipse merge.
> So, maybe things are different now.
Sure, they are fixed [1].
[1]: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01386.html
--- Comment #6 from ubizjak at gmail dot com 2009-09-29 21:52 ---
This is fixed in 4.3+:
All fixinclude tests pass
make[2]: Leaving directory `/space/uros/gcc-build-43/fixincludes'
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-29 21:42 ---
I've looked at what code generation changes the jump from r151310 to r151312
(aka VTA merge) and on eon.cc at -O3 -funroll-loops -fpeel-loops on ia64-linux
the difference is that r151310 unroll something that r151312 d
--- Comment #9 from ubizjak at gmail dot com 2009-09-29 21:41 ---
(In reply to comment #6)
> Can someone check if this still fails on latest 4.3 branch?
It doesn't. See [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01497.html
--
ubizjak at gmail dot com changed:
--- Comment #6 from ubizjak at gmail dot com 2009-09-29 21:18 ---
Not alpha specific, happens on current mainline, where on x86_64 we produce the
code as shown in comment #5.
I think that Richi will be interested in the fact that the usage of __restrict
does not change generated code in
--- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 ---
There are already peepholes for this, though the condition appears to be
slightly wrong for -Os. See i386.md:21121 :
(define_peephole2
[(match_scratch:SI 1 "r")
(set (match_operand:SI 0 "memory_operand" "")
--- Comment #5 from falk at debian dot org 2009-09-29 21:02 ---
Of course the optimization would be wrong if the second clause had side
effects, but it doesn't and this will frequently be the case. So this is
definitely a valid and in my opinion worthwhile optimization.
--
http://gc
--- Comment #39 from rth at gcc dot gnu dot org 2009-09-29 20:54 ---
(In reply to comment #35)
> static tree
> build_function_type_list_1 (bool vaargs, tree return_type, va_list argp)
Passing va_list by value is non-portable. One fix here is to pass argp
by reference. Dunno if that fi
--- Comment #4 from ubizjak at gmail dot com 2009-09-29 20:53 ---
In fact, this implements short-cut of boolean OR. Function returns early for x
== 0 and should not execute right part of OR expression in this case. Something
like:
if (x == 0 || (x & (x - 1)) == 0)
return 1;
else
ret
--- Comment #3 from ubizjak at gmail dot com 2009-09-29 20:45 ---
This is not alpha specific, but generic tree issue.
The _.optimized dump:
:
if (x_2(D) == 0)
goto ;
else
goto ;
:
D.2022_3 = x_2(D) + -1;
D.2023_4 = D.2022_3 & x_2(D);
D.2016_9 = D.2023_4 == 0;
:
#
--- Comment #7 from mwarshofsk at aol dot com 2009-09-29 20:34 ---
Comment 6 is perfect! That makes total sense. Thanks so much! Actually, I bet
the Solaris compiler is implicitly treating this same code as a const & String
behind the scenes. We'll just explicitly make that promise/fix f
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-29 20:08 ---
If the ctor isn't going to change it, you could as well change the argument
type to const String & instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
--- Comment #6 from tromey at gcc dot gnu dot org 2009-09-29 20:03 ---
*** Bug 39708 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
--- Comment #2 from tromey at gcc dot gnu dot org 2009-09-29 20:03 ---
This is obsoleted by the newer idea in PR 41130.
*** This bug has been marked as a duplicate of 41130 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-09-29 19:41 ---
Yes GCC is correct as in C++ rvalues don't bind to references as only lvalues
bind to references.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from mwarshofsk at aol dot com 2009-09-29 19:32 ---
Here's the definition for that call ... I think you're on to something
String get_job_title_mgmt_ind() const { return _jobTitleMgmtInd; };
When I change the constructor to "non reference" paramters it seems to compile
f
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-09-29 19:25 ---
What type does get_job_title_mgmt_ind return?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
--- Comment #2 from mwarshofsk at aol dot com 2009-09-29 19:24 ---
This is the method where I am receiving the compiler error:
enum err_stat EJPeriod::rollup( List &src, List &dst,
Date &startDt, Date &endDt )
{
// then theres a bunch of code
// and the
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 19:15 ---
Can you show the line where the call to EJPeriod::EJPeriod is done? It might
be because String that you are passing is a rvalue which cannot be bound to
String& as that would mean it needs to be bound to a lvalue.
--- Comment #16 from jv244 at cam dot ac dot uk 2009-09-29 18:59 ---
since graphite should be able to fix this PR, I tried it without luck:
> gfortran -ffast-math -O3 -march=native -fgraphite -floop-interchange
> -floop-block test.f90
test.f90: In function MAIN__:
test.f90:1:0: sorry
I am currently porting an app from Sun Solaris where we use the Solaris cc
compiler (version 5.8). Have a 12 year old legacy app that compiles "fine" in
the current environment :-)
While trying to migrate to RedHat Linux and the GNU g++ compiler (version
4.1.2) I am repeatedly running into "error:
--- Comment #2 from ubizjak at gmail dot com 2009-09-29 18:47 ---
(In reply to comment #1)
> This was fixed on the trunk, I don't have the changelog entry handy though,
> but
> it was done by Jakub IIRC.
2009-08-07 Jakub Jelinek
* dwarf2out.c (output_fde): When doing hot/co
--- Comment #38 from ubizjak at gmail dot com 2009-09-29 18:36 ---
(In reply to comment #37)
> Can you please attach pre-processed source of it so that I can try
> running it through a cross-compiler?
>
> Additionally, -fdump-tree-cddce-slim and -fdump-tree-eipa_sra-details
> dumps w
--- Comment #3 from hjl at gcc dot gnu dot org 2009-09-29 18:29 ---
Subject: Bug 41496
Author: hjl
Date: Tue Sep 29 18:29:24 2009
New Revision: 152287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152287
Log:
2009-09-29 H.J. Lu
PR testsuite/41496
* g++.dg/df
--- Comment #1 from ro at gcc dot gnu dot org 2009-09-29 18:09 ---
Testing the trivial fix on Solaris 10/x86 to see how far this gets me.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-09-29 18:02 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02117.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-29 17:36 ---
Hi Janis, I think one of your patches causes this. It removed
"-ansi -pedantic-errors -Wno-long-long" in the second run for
--target_board 'unix{-m32,}'.
--
hjl dot tools at gmail dot com changed:
Wha
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-29 17:40 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-29 17:39 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-29 17:34 ---
Subject: Bug 41474
Author: jakub
Date: Tue Sep 29 17:33:58 2009
New Revision: 152282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152282
Log:
PR debug/41438
* dwarf2out.c (const_ok_for_output
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 17:34 ---
Subject: Bug 41438
Author: jakub
Date: Tue Sep 29 17:33:58 2009
New Revision: 152282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152282
Log:
PR debug/41438
* dwarf2out.c (const_ok_for_output
--- Comment #2 from law at redhat dot com 2009-09-29 17:12 ---
I don't understand your comment Richard. Isn't it just something like this?
(define_peephole2
[(match_scratch:SI 2 "r")
(set (match_operand:SI 0 "memory_operand" "")
(match_operand:SI 1 "const_0_operand" ""))]
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-09-29 16:52 ---
(In reply to comment #1)
> The following patch fixes the problem, I will send it to the mailing
> list soon:
>
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02105.html
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-09-29 16:42 ---
The following patch fixes the problem, I will send it to the mailing
list soon:
2009-09-29 Martin Jambor
PR c++/41503
* cp/pt.c (function_parameter_expanded_from_pack_p): Return false if
The gfortran manual's documentation about MAXLOC/MINLOC is misleading. It
claims that the 'array' argument may be of CHARACTER type, which is true for
Fortran 2003.
However, the manual claims the intrinsic is Fortran 90/95 without further
notice about CHARACTER type being allowed only since F2003
--- Comment #37 from jamborm at gcc dot gnu dot org 2009-09-29 16:16
---
(In reply to comment #34)
> It is tree.o object of stage2 gcc that gets miscompiled when -fipa-sra is
> added
> to BOOT_CFLAGS. If tree.o is substituted with the one from the build without
> BOOT_CFLAGS, gcc is ag
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 16:09 ---
Can't reproduce with x86_64-linux -> s390x-linux cross (-O3 -m31).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 16:07 ---
difficult
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 16:06 ---
It would be helpful to know what you are patching, because neither 4.4 branch
nor trunk gcov.c has anything like that, see e.g.
http://sources.redhat.com/viewcvs/gcc/branches/gcc-4_4-branch/gcc/gcov.c?revision=145122&v
--- Comment #1 from jason dot vas dot dias at gmail dot com 2009-09-29
15:59 ---
Created an attachment (id=18666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18666&action=view)
Patch to fix gcov
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41506
Every gcov test in the gcov testsuite
( gcc/testsuite/gcc.misc-tests/gcov.exp )
fails because gcov gets a SIGSEGV
on its first invocation of 'fgets()' -
'char *fgets_unlocked( char *buf, size_t size, FILE *stream )
'
is NOT declared, because '__USE_GNU' is NOT defined ;
__USE_GNU is explic
Consider:
foo(int *x)
{
*x = 0;
}
Compile with -Os -fomit-frame-pointer and you'll get something like this:
movl4(%esp), %eax
movl$0, (%eax)
It would be 2 bytes shorter to instead load the constant 0 via an xor
instruction into a scratch register, then store the scratc
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
--- Comment #2 from DumaShkurko at gmail dot com 2009-09-29 15:09 ---
Is it possible to adjust specs file for -static and/or -pthread?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41504
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 14:58 ---
This was fixed on the trunk, I don't have the changelog entry handy though, but
it was done by Jakub IIRC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-29 14:40 ---
My http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02070.html patch fixes this
too.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 14:31 ---
You need to link libpthread.a with -Wl,--whole-archive
In general static linking is not recommended with glibc and threads.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
Hello,
Compile the following file with gcc:
void s () {
pthread_cancel();
/*pthread_mutex_trylock (); */
}
and the following file with gfortran:
program test
print*, "Bug"
end program test
Link both files using "gfortran -static -pthread". Note that the program dies
with SEGV in pthread_
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 14:21 ---
Subject: Bug 41502
Author: rguenth
Date: Tue Sep 29 14:20:37 2009
New Revision: 152277
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152277
Log:
2009-09-29 Richard Guenther
* gcc.dg/visibility-7
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-29 14:20 ---
Papered over.
./xgcc -B. -o t.o -shared attr-warn-unused-result.3.i -O -fPIC -flto
still ICEs the old way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41502
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 14:04 ---
static void
ipa_passes (void)
{
...
/* Remove the bodies of extern inline functions that we never
inlined. */
cgraph_remove_unreachable_nodes (false, dump_file);
that's bogus and too early.
--
rguenth
function_parameter_expanded_from_pack_p() segfaults when compiling
20_util/reference_wrapper/24803.cc and IPA-SRA turned on. The reason
is that it is presented a PARM_DECL that was created by IPA-SRA and
which does not have language specific data.
The backtrace is:
#0 0x004b872f in funct
--- Comment #31 from jamborm at gcc dot gnu dot org 2009-09-29 13:49
---
(In reply to comment #12)
> Thus I believe SRA has nothing to
> do with these remaining failures. If you want to confirm this
> independently, compile them with -fno-tree-sra.
>
...and so I un-assign this bug fr
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 13:46 ---
Reduced testcase, fails at -O1:
typedef void (*fnt) (void);
extern inline void check3 (void)
{
bar ();
}
void test (void)
{
const fnt pcheck3 = check3;
pcheck3 ();
}
all details important: extern, the call t
gcc.dg/attr-warn-unused-result.c ICEs in
Program received signal SIGSEGV, Segmentation fault.
0x00c790bc in expand_call_inline (bb=0x771a0a10,
stmt=0x77198000, id=0x7fffd810)
at /space/rguenther/src/svn/lto/gcc/tree-inline.c:3661
3661 gcc_assert (!id->src_cfun->af
--- Comment #3 from laurent at guerby dot net 2009-09-29 13:38 ---
Together with PR41493 these are the only two ACATS fail on arm-linux as of rev
152122:
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02662.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41325
--- Comment #2 from joel at gcc dot gnu dot org 2009-09-29 13:35 ---
Add powerpc-rtems4.10 to the list of targets that fail.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from laurent at guerby dot net 2009-09-29 13:32 ---
This happens also on arm-linux at rev 152122
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02662.html
.,. C34006G ACATS 2.5 09-09-28 14:27:54^M
C34006G CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED
gcc-4.4.2 testsuite failures:
FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
using binutils 2.20.51.20090927
Copying sources to a temporary directory and repeating commands used by
testsuite
Since 4.4 i'm unable to rebuild gcc, check downstream bug:
http://bugs.gentoo.org/286251
Steps to reproduce:
- extract gcc-4.4.1 tarball
-./configure
-make LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O
LIBPATH=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.1 'BOOT_CFLAGS=
-march=armv5te -pipe -O2' bootstrap
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 12:58 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-29 12:58 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-29 12:58 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-29 12:58
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-29 12:57 ---
Subject: Bug 41444
Author: jakub
Date: Tue Sep 29 12:56:46 2009
New Revision: 152275
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152275
Log:
PR testsuite/41444
* gcc.dg/guality/guality.h (GU
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 12:56 ---
Subject: Bug 41467
Author: rguenth
Date: Tue Sep 29 12:56:29 2009
New Revision: 152274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152274
Log:
2009-09-29 Richard Guenther
PR lto/41467
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 12:56 ---
Subject: Bug 40754
Author: rguenth
Date: Tue Sep 29 12:56:29 2009
New Revision: 152274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152274
Log:
2009-09-29 Richard Guenther
PR lto/41467
1 - 100 of 121 matches
Mail list logo
