--- Comment #24 from mikpe at it dot uu dot se 2010-05-11 06:51 ---
Your gcc appears confused about whether to use the newer _Unwind_GetIPInfo() or
the older _Unwind_GetIP(). Most likely it's because you're building for uclibc
rather than glibc. I think you need to bisect between the las
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-11 06:48 ---
Subject: Bug 44023
Author: jakub
Date: Tue May 11 06:48:15 2010
New Revision: 159254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159254
Log:
PR debug/44023
* df-problems.c (struct dead_debu
--- Comment #3 from ubizjak at gmail dot com 2010-05-11 06:45 ---
Oops, wrong cut-n-paste. This is correct:
Program received signal SIGSEGV, Segmentation fault.
0x000120192df8 in fixup_reorder_chain ()
at ../../gcc-svn/trunk/gcc/cfglayout.c:889
889 if (bb->aux == e
--- Comment #2 from ubizjak at gmail dot com 2010-05-11 06:32 ---
Confirmed with 4.6.0 mainline:
Program received signal SIGSEGV, Segmentation fault.
0x0056d5b8 in cfg_layout_finalize ()
at ../../gcc-svn/trunk/gcc/cfglayout.c:477
477 if (loc == prologue_locator || loc
--- Comment #23 from dougmencken at gmail dot com 2010-05-11 05:53 ---
(In reply to comment #22)
> "make install" should do it
make install of course does it (if --enable-shared is supplied to ./configure)
> look to see if libgcc_s.so is built, is it in the build tree?
I'm now on stage
--- Comment #1 from hpa at zytor dot com 2010-05-11 05:39 ---
Created an attachment (id=20624)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20624&action=view)
Test case
Compiled with:
gcc -O2 -fomit-frame-pointer -S -o jumptest.s jumptest.c
--
http://gcc.gnu.org/bugzilla/sh
The attached test case ICE's with the __builtin_unreachable() enabled. With
the __builtin_unreachable() disabled, it compiles, but produces bad code:
.file "jumptest.c"
.text
.p2align 4,,15
.globl xyzzy
.type xyzzy, @function
xyzzy:
.LFB1:
.cfi_startpro
--- Comment #4 from law at redhat dot com 2010-05-11 05:31 ---
I doubt my work will make a significant difference for this test.
We're trying to reload an insn which matches:
(define_insn "*add3_cconly_overflow"
[(set (reg:CCC FLAGS_REG)
(compare:CCC
(plus:SWI
--- Comment #2 from astrange at ithinksw dot com 2010-05-11 03:38 ---
Created an attachment (id=20623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20623&action=view)
testcase
This happens building ffmpeg on x86-64 now. Minimal-ish testcase attached.
--
http://gcc.gnu.org/bu
--- Comment #4 from carrot at google dot com 2010-05-11 03:21 ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00263.html.
--
carrot at google dot com changed:
What|Removed |Added
---
--- Comment #4 from jason at gcc dot gnu dot org 2010-05-11 02:18 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Summary|ICE in
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-11 01:18 ---
Most likely the same as PR 44063.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44070
xgcc (GCC) 4.6.0 20100510 (experimental) [trunk revision 159244]
/users/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/users/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem
/users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-11 00:44
---
Bah... let's see what Richard thinks. Personally, I would have written it like
this in the first place:
#include
template
class M {
public:
M( const double arr[R][C] ) {
for (unsigned r = 0; r <
--- Comment #2 from kraftche at cae dot wisc dot edu 2010-05-11 00:29
---
Subject: Re: optimization bug initializing from cast array
On 05/10/2010 07:22 PM, pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-11 00:22
> ---
> Th
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-11 00:22 ---
The problem is that you are reading past the array (vals[0]).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44069
The code below, when compiled with out optimization, produces the expected
result:
% g++ bug.cc -o bug
% ./bug
{1, 2, 3, 4}
{5, 6, 7, 8}
{9, 0, 1, 2}
{3, 4, 5, 6}
When compiled with optimization, it produces garbage for all rows of the matrix
except the first row:
% g++ -O2 bug.cc -o bug
% ./bug
--- Comment #1 from jingyu at google dot com 2010-05-10 23:52 ---
I see the same error when compiling thumb2 libgcc.
Host=Build=x86_64-unknown-linux-gnu, Target=arm-unknown-eabi
The error message points to following lines in gcc/config/arm/lib1funcs.asm.
cmp \dividend, #0
--- Comment #9 from svfuerst at gmail dot com 2010-05-10 23:27 ---
Remember that isnan() is a weird type-dependent macro. The special case I was
testing is the __float128 version. __float128's are passed in sse registers,
so using sse instructions to manipulate them can be a win. (No
--- Comment #17 from fmartinez at gmv dot com 2010-05-10 23:22 ---
So it seems tht the bug is not gone. I have tried again with version from May
8th and I still get the problem on line 556.
I tried to submit a comment yesterday but it seems that it failed. Here it goes
again.
--
fmar
--- Comment #1 from jay dot krell at cornell dot edu 2010-05-10 23:01
---
ps:
#if (defined (__FreeBSD__) && (__FreeBSD__>= 5)) || defined(__vms)
can probably just be:
#if __FreeBSD__>= 5 || defined(__vms)
or:
#if __FreeBSD__ | __vms
assuming the #define can also be be ommited on Fre
--- Comment #4 from devinull dot v42 at gmail dot com 2010-05-10 22:57
---
(In reply to comment #2)
> Your operator< is not valid. It must be a strict-weak ordering.
>
> In particular, it must not be possible that A < B and B < A, but in your code
> this is possible.
>
Thank you, Chri
--- Comment #1 from jay dot krell at cornell dot edu 2010-05-10 22:53
---
adding Andrew and his mail to bug:
For builtins you should look at how PowerPC Darwin handles the long double
builtins since they are renamed if long double is 128bit.
Thanks,
Andrew Pinski
--
jay dot krell
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-10 22:50
---
Thanks Chris.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-05-10 22:49 ---
>Anyway, the result of much benchmarking shows that:
Is it? It definitely moves from the x87 registers to the SSE registers which
can be slow. Micro benchmarks are not always true benchmarks. Also there are
other
--- Comment #7 from svfuerst at gmail dot com 2010-05-10 22:44 ---
Perhaps an example usage helps:
The __float128 version of isnan() is rather slow. Trying different
implmentations to see which is faster required some benchmarking. However,
implementing the benchmark code requires an
--- Comment #2 from chris at bubblescope dot net 2010-05-10 22:44 ---
Your operator< is not valid. It must be a strict-weak ordering.
In particular, it must not be possible that A < B and B < A, but in your code
this is possible.
--
chris at bubblescope dot net changed:
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-10 22:31 ---
Why this is a standard unix issue and not really a GCC issue. The same could
be said about any program you want to build that uses ar (which is almost all
programs that use static libraries).
--
pinskia at gcc d
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-10 22:27
---
Please provide a short snippet, inline here, no more than 20-30 lines, no data,
or other redundant information. Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #2 from jay dot krell at cornell dot edu 2010-05-10 22:21
---
It'd be nice if:
../src/configure
gmake
gmake install
worked with a minimum of customizations.
As I understand: ar is not in the default $PATH on Solaris, but it is always
installed to the same place: /u
It looks like bug thag std::map can create it's elements without calling it's
constructors and compare keys of such objects. This is example code that
illustrates problem. Every time new object of type Node is constructed it's
address is stored in vector "ptrs". Any time member function is called v
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-10 22:12 ---
Removed dependence on PR44054, handling those options is not (strictly)
required here. Nice yes,required, no ;)
Assigning to myself, patch is regtesting.
--
dfranke at gcc dot gnu dot org changed:
Wh
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-10 22:11 ---
NULLPTR_TYPE is only defined in cp/cp-tree.def which means if you configure
without C++, this fails to compile. Yes this is a big bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #57 from pinskia at gcc dot gnu dot org 2010-05-10 22:06
---
*** Bug 44066 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-10 22:06 ---
*** This bug has been marked as a duplicate of 14179 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-10 22:06 ---
Confirmed.
Compiling via ...
gfortran-4.6 -c module.f90
gfortran-4.6 test.f90
... works, though.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-05-10 22:04 ---
Also I think it is a bad idea for having this kind of attribute. If your
benchmark can be optimized away, that is better for newer versions of the
compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44053
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-10 22:03 ---
If ar is not in your path, there is no GCC bug here really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-10 21:59 ---
For me, compiling the code in comment #0 in a single file seems to get stuck in
an endless loop (trunk rev. 159217 on x86_64-unknown-linux-gnu).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
--- Comment #8 from steven at gcc dot gnu dot org 2010-05-10 21:29 ---
IMA will not be fixed. Actually, it never worked properly to begin with...
GCC 4.5 has -flto, but I don't expect it will do much better than IMA, from a
memory usage point of view. GCC 4.5 also has -fwhopr, but that
--- Comment #3 from jason at gcc dot gnu dot org 2010-05-10 21:21 ---
Subject: Bug 44017
Author: jason
Date: Mon May 10 21:20:47 2010
New Revision: 159246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159246
Log:
PR c++/44017
* semantics.c (baselink_for_fns): Re
gcc 4.5.0 fails to build libgcc when configured as follows
/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/configure
--build=x86_64-linux --host=x86_64-linux --target=powerpc-oe-linux-gnuspe
--prefix=/scratch/oe/calamari/cross/ppce500v2
--exec_prefix=/scrat
--- Comment #3 from fabien dot chene at gmail dot com 2010-05-10 21:12
---
This is valid code, the use of the temporary value-initializes the const
member.
--
fabien dot chene at gmail dot com changed:
What|Removed |Added
-
--- Comment #17 from davek at gcc dot gnu dot org 2010-05-10 20:54 ---
(In reply to comment #16)
> On alphaev68-pc-linux-gnu, I'm getting:
> FAIL: leaktest
> 1 of 4 tests failed
> Is this failure something to worry about?
The honest answer is: I can't tell you. These are test cases t
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-10 20:15 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-10 20:05 ---
Subject: Bug 44028
Author: jakub
Date: Mon May 10 20:05:09 2010
New Revision: 159244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159244
Log:
PR debug/44028
* haifa-sched.c (schedule_insn): W
--- Comment #16 from rsandifo at gcc dot gnu dot org 2010-05-10 19:49
---
Thanks Andreas. I don't have access to m68k-elfy targets these days, so could
someone test it just to be sure? I'll commit if everything goes OK.
--
rsandifo at gcc dot gnu dot org changed:
What
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-10 19:29
---
We should now have about the same behaviour as with C.
The additional requests in comment #4 (integer division) are not handled by the
patch in #9. These are special cases and not necessarily related to
-Wconversi
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-10 19:26 ---
(In reply to comment #6)
> The bad pointer position is another instance of the many PRs complaining about
> this. I think this PR should be closed after a patch for -Wconversion was
> applied and a new one for the er
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-10 19:24 ---
Fixed. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #9 from mikael at gcc dot gnu dot org 2010-05-10 18:42 ---
This depends on the double decl problem, which is :
if a module is both defined and used in the same file, we create new symbols
when we load the module, instead of reusing/sharing them.
(In reply to comment #8)
>
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #13 from jason at gcc dot gnu dot org 2010-05-10 18:40 ---
Fixed for 4.6.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #12 from jason at gcc dot gnu dot org 2010-05-10 18:38 ---
Subject: Bug 44045
Author: jason
Date: Mon May 10 18:37:56 2010
New Revision: 159243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159243
Log:
PR c++/44045
* typeck.c (cp_build_modify_expr):
--- Comment #6 from jason at gcc dot gnu dot org 2010-05-10 18:37 ---
Subject: Bug 43719
Author: jason
Date: Mon May 10 18:37:45 2010
New Revision: 159242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159242
Log:
PR c++/43719
* decl.c (check_initializer): strip
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-10 18:28 ---
Subject: Bug 44028
Author: jakub
Date: Mon May 10 18:28:03 2010
New Revision: 159240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159240
Log:
PR debug/44028
* haifa-sched.c (schedule_insn): W
--- Comment #2 from mikael at gcc dot gnu dot org 2010-05-10 18:25 ---
(In reply to comment #1)
> Confirmed. Dependency analysis should see that no temporary is required here.
>
As both Rx and Ry have the pointer attribute, I'm not so sure about it.
Note that if one removes the pointe
Description:
Compiling an array with an initializer list takes memory roughly 140 times the
size of the array. For example, and array of unsigned char with 1M entries
(i.e., sizeof is 1MB), takes 140 MB to compile. An array of 5MB requires over
600MB of memory to compile. Below are some rough meas
--- Comment #3 from mikael at gcc dot gnu dot org 2010-05-10 17:35 ---
If I understand correctly, an external symbol can be used for a common block
name in f2003.
Thus, there should be no error with -std=f2003.
--
mikael at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from redi at gcc dot gnu dot org 2010-05-10 17:32 ---
(In reply to comment #10)
> So you can see that g++ sees this as valid code.
I think that's a bug too
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-10 17:32 ---
On x86_64-apple-darwin10, I do not see any difference between this PR and
pr44064. On powerpc-apple-darwin9, I get the errors reported in pr44064#c2 when
compiling the module file.
--
http://gcc.gnu.org/bugzilla/
--- Comment #22 from redi at gcc dot gnu dot org 2010-05-10 17:28 ---
(In reply to comment #17)
> So can you please tell me how to "install libgcc" then?
"make install" should do it. if it's not, look to see if libgcc_s.so is built,
is it in the build tree? does the one in the build tr
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-10 17:21 ---
On powerpc-apple-darwin9 at revision 159191 (without gfortran patch) I get:
[karma] f90/bug% gfc pr44064.f90
/var/tmp//ccpUV3i0.s:65:non-relocatable subtraction expression,
"_vtab$inner.1183" minus "L001$pb"
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-10 17:19 ---
On x86_64-apple-darwin10 at revision 159234 (+ a few patches) I get:
[macbook] f90/bug% gfc pr44064.f90
Undefined symbols:
"_vtab$inner.1583", referenced from:
___module_mysubclass_MOD_init in cc4CUNex.o
--- Comment #10 from dougsemler at gmail dot com 2010-05-10 17:18 ---
Well, is it really invalid code with -std=c++0x?
The virutal destructor seems to be causing the issue.
With gcc 4.4.3 (after changing virtual ~base() to virtual void func()):
$ g++ gcc_bug.cc
gcc_bug.cc: In functio
In the following testcase (tested against 4.6), a procedure bound to an
attribute of a super class is not resolved in the subclass.
The test case below doesn't go through the linker.
The error message is:
> gfortran -c -ffree-form module.f test.f
> gfortran -o test test.o module.o
module.o: In f
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-10 17:16 ---
(In reply to comment #2)
> This probably superseeds (accompanies?) PR31601.
Not really. This is about warnings - the other is about errors due to -std=.
For warnings, the purpose is to help fine-tuning the warnings -
--- Comment #8 from mikael at gcc dot gnu dot org 2010-05-10 17:16 ---
(In reply to comment #7)
> With -fwhole-file I now get the same timings either way. I call that fixed.
>
Unless there is one other bug tracking inlining of use-associated functions,
one cannot close this yet.
The co
--- Comment #11 from ubizjak at gmail dot com 2010-05-10 17:15 ---
(In reply to comment #10)
> I'd say that the patch is OK.
Regression test results at [1], everything looks OK.
[1] http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00960.html
--
http://gcc.gnu.org/bugzilla/show_bu
The following testcase segfaults in 4.6:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type inner
type :: myclass
type(inner) :: slice
end type myclass
contains
subroutine set(this)
class(inner), intent(inou
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 42809
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
PR fortran
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 35003
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
PR fortran
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 27866
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
PR fortran
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-10 17:02 ---
I think -Wconversion-extra would be a good choice.
We could enable -Wconversion with -Wall and -Wconversion-extra with -Wextra?!
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from ubizjak at gmail dot com 2010-05-10 17:01 ---
On alphaev68-pc-linux-gnu, I'm getting:
make[4]: Entering directory
`/space/uros/gcc-build/alphaev68-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
A
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-10 16:58 ---
This probably superseeds (accompanies?) PR31601.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-10 16:50 ---
Created an attachment (id=20622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20622&action=view)
gcc46-pr44062.patch
Actually, I've found 2 issues even in the C FE related to comma expressions
with
LHS or RHS w
--- Comment #21 from bernhardloos at googlemail dot com 2010-05-10 16:48
---
*** Bug 44060 has been marked as a duplicate of this bug. ***
--
bernhardloos at googlemail dot com changed:
What|Removed |Added
-
--- Comment #5 from bernhardloos at googlemail dot com 2010-05-10 16:48
---
It is a duplicate, my problem happens in exactly the same place.
Sorry I missed the other bug.
*** This bug has been marked as a duplicate of 43987 ***
--
bernhardloos at googlemail dot com changed:
--- Comment #1 from hp at gcc dot gnu dot org 2010-05-10 16:35 ---
Created an attachment (id=20621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20621&action=view)
Preprocessed code, slightly reduced.
Compile with "./cc1 -O2 t.i", observe ICE as in the description.
--
http:/
--- Comment #21 from pluto at agmk dot net 2010-05-10 16:31 ---
(In reply to comment #20)
> But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?
configure binutils with --disable-shared --enable-static and build
with make AM_LDFLAGS="-all-static". you also need to hav
With revision 159199 the trunk built for cris-elf.
With revision 159204 and on, including at least 159229, build was broken as
follows:
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -i
--- Comment #4 from pluto at agmk dot net 2010-05-10 16:26 ---
(In reply to comment #3)
> Gcc 4.6 generates expected code.
>
PR43987 dupllication?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44060
--- Comment #20 from dougmencken at gmail dot com 2010-05-10 16:23 ---
But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?
$ ./print-sharedlib-deps.sh /usr/bin/ld
/usr/bin/ld:
libz.so.1
libc.so.0
libgcc_s.so.1
Now I'm using libgcc_s.so.1 copi
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-10 16:16 ---
Gcc 4.6 generates expected code.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ramana at gcc dot gnu dot org 2010-05-10 16:03 ---
Confirmed - marking as a target bug .
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-10 15:51 ---
Created an attachment (id=20620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20620&action=view)
testcases
2 new testcases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44062
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-10 15:48 ---
Oops, seems something I should have covered in the testsuite. For C it works
correctly.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-10 15:32 ---
It is caused by revision 158806:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00913.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #9 from jason at gcc dot gnu dot org 2010-05-10 15:30 ---
The testcase is invalid; 5.17 doesn't allow assignment to an array from an
initializer list (although I'm not sure why not). But certainly we should give
an error rather than crash.
--
jason at gcc dot gnu dot org
--- Comment #3 from vmakarov at redhat dot com 2010-05-10 15:22 ---
> It is caused by revision 152533:
>
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00182.html
>
If it is so, the patch triggered some reload bug IMO. The patch itself was
very safe because it resulted in creation of ad
Doing
(void)var;
does not 'use' the var, eg:
void f()
{
int i = 6; // or a fn call whose return value you don't care about
(void)i;
}
j...@shade:~$ g++ -Wall -Wextra unused.cpp
unused.cpp: In function void f():
unused.cpp:3:8: warning: variable i set but not used
[-Wunuse
--- Comment #2 from bernhardloos at googlemail dot com 2010-05-10 14:57
---
(In reply to comment #1)
> Try -Wstrict-aliasing.
>
It does produce a warning about dreferencing a type-punned pointer.
I tried to compile the snipped with both -fstrict-aliasing and
-fno-strict-aliasing and i
--- Comment #5 from svfuerst at gmail dot com 2010-05-10 14:53 ---
The problem is that the list of these workarounds tends to increase with each
release of gcc. (i.e. noclone was added in gcc 4.5) It would be nice if there
was a single attribute to use that would work with all future ve
--- Comment #1 from schwab at linux-m68k dot org 2010-05-10 14:43 ---
Try -Wstrict-aliasing.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
Stat
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-10 14:39 ---
Reopening.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-10 14:39 ---
I guess the problem is in the !DECL_ARTIFICIAL (DECL) test in
ASM_DECLARE_OBJECT_NAME macro - the guard is artificial.
Not sure why that has been added.
/* For template static data member instantiations or
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-10 14:38 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
int a[2];
int foo (int q)
{
if (__builtin_constant_p (q))
{
if (q == 4)
return a[4];
else
return a[0];
}
else
return a[q];
}
--
Summary: [4.5/4.6 Regression] Warns about out-of-bounds array
access inside __builtin_constan
1 - 100 of 136 matches
Mail list logo
