--- Comment #2 from miles at gnu dot org 2010-04-20 06:52 ---
Created an attachment (id=20434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20434&action=view)
"local-surface-pp.cc", gzipped
the uncompressed version of this file was too large to attach
[note that the actual sourc
--- Comment #23 from pault at gcc dot gnu dot org 2010-04-20 06:19 ---
Created an attachment (id=20433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20433&action=view)
fix for this PR and PR43266
The attached is what I intend to submit tonight, unless somebody approves it in
the
--- Comment #1 from miles at gnu dot org 2010-04-20 05:59 ---
The bug system won't let me attach the file, so I've got to find someplace to
stash it:
"The file you are trying to attach is 1367 kilobytes (KB) in size. Non-patch
attachments cannot be more than 1000 KB."
--
http://gcc
The compiler is actually from the debian "gcc-snapshot" package, version
20100414-1. The same error occurs using the debian g++-4.5 package (version
4.5-20100404-1).
The same error occurs for many source-files in my program, so I've just picked
one.
I will attach the pre-processed source-file af
--- Comment #3 from yves dot caniou at ens-lyon dot fr 2010-04-20 05:32
---
Note: "$HOME" replaces the correct absolute path in the output of the "make
install" command
--
yves dot caniou at ens-lyon dot fr changed:
What|Removed |Added
--
--- Comment #7 from ian at airs dot com 2010-04-20 05:14 ---
I know the problem is vec_concatv2si_sse and friends. My question is why we
use that insn for _mm_cvtsi32_si64.
Any comments on the documentation issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43743
--- Comment #22 from pault at gcc dot gnu dot org 2010-04-20 05:00 ---
(In reply to comment #21)
>
> Could you explain what the other stuff is needed for? I currently fail to see
> that.
>
Ignore the first bit in resolve.c,
The change to trans-decl.c fixes the second segfault. The
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-20 03:18 ---
It worked (not producing an ICE) with:
GNU C++ (GCC) version 4.5.0 20100401 (experimental) [trunk revision 157933]
(x86_64-unknown-linux-gnu)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43790
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-20 03:16 ---
With a release branch you don't see the internal error but rather a message
saying confused by previous error :). So users of the released compiler never
see the ICE.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from yves dot caniou at ens-lyon dot fr 2010-04-20 03:15
---
(In reply to comment #1)
> (In reply to comment #0)
> > Dear All,
> >
> > I want to compile gcc-4.5.0 on a Quad-Core AMD Opteron(tm) Processor 8356
> > in my
> > user repository.
> > The compiler is gcc versio
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-04-20 03:14 ---
It was introduced by:
2010-04-15 Steven G. Kargl
PR fortran/30073
* trans-array.c (gfc_trans_array_bound_check): Eliminate a redundant
block of code. Set name to the variable associated w
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-20 03:08 ---
(In reply to comment #2)
> Another -O0 -fipa-* bug.
Actually it also fails with "-fipa-cp -fipa-cp-clone -O2 -fno-inline" so this
is not just a -O0 issue but something going funny with the ipa-cp cloner.
--
htt
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-20 03:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-20 02:49 ---
Most likely a dup of bug 43415.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43811
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-20 02:48 ---
Looks to get good in 4.5.0 and on the trunk:
TOTAL : 0.98 0.02 1.41
18816 kB
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43811
--- Comment #2 from wuwei08 at iscas dot ac dot cn 2010-04-20 02:44 ---
Created an attachment (id=20432)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20432&action=view)
another source file can trigger this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43811
--- Comment #1 from wuwei08 at iscas dot ac dot cn 2010-04-20 02:41 ---
Created an attachment (id=20431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20431&action=view)
the source file trigger the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43811
gcc 4.4.3 exhausted all memory(3.2G) and got stuck in an infinite loop:
gcc-4.4.3 -O3 MTest-1.c
while gcc-4.4.1 works fine with the same option.
gcc-4.4.3 config options:
^_^ $../../exe/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src/configure
--prefix=/home/wuwe
--- Comment #7 from tomdean at speakeasy dot org 2010-04-20 02:29 ---
Subject: Re: Tanh Returns Incorrect Value
On Tue, 2010-04-20 at 01:58 +, pinskia at gcc dot gnu dot org wrote:
Thanks for clearing that up.
Please close the bug report.
I filed a bug with glibc.
Thanks.
--
--- Comment #18 from paolo dot carlini at oracle dot com 2010-04-20 02:23
---
I largely agree with Jon. Note, at this stage in the standardization process
it's pretty difficult to change the working draft. Agreed, std::pair will be
different wrt the FCD, but if somebody want to change t
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-04-20 01:58 ---
D.26220_58 = COMPLEX_EXPR ;
s$_M_value_60 = __builtin_csinhl (D.26220_58);
s$_M_value$real_99 = REALPART_EXPR ;
s$_M_value$imag_105 = IMAGPART_EXPR ;
c$_M_value_62 = __builtin_ccoshl (D.26220_58);
c$_M_va
--- Comment #4 from wilson at codesourcery dot com 2010-04-20 01:54 ---
Subject: Re: [4.6 regression] New test failures
On Tue, 2010-04-20 at 00:01 +, sje at cup dot hp dot com wrote:
> Any ideas on how to fix the compiler? The best idea I could come up with was
> to check each ba
--- Comment #5 from tomdean at speakeasy dot org 2010-04-20 01:37 ---
Subject: Re: Tanh Returns Incorrect Value
On Mon, 2010-04-19 at 23:57 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-19 23:57
> ---
> And tanhl
--- Comment #3 from patrick at motec dot com dot au 2010-04-20 01:28
---
I've just done a fresh gcc build and crtsavgpr.asm crtresgpr.asm and friends
definitely aren't being assembled.
Am I expected to provide these functions in the library layer of my operating
system?
--
http://
--- Comment #7 from wilson at gcc dot gnu dot org 2010-04-20 01:17 ---
Subject: Bug 43520
Author: wilson
Date: Tue Apr 20 01:16:59 2010
New Revision: 158539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158539
Log:
partial fix, make all 'e' class regs fixed
PR rtl-optimization/
--- Comment #13 from navin dot kumar at gmail dot com 2010-04-20 01:13
---
Example:
//test.cc
class empty_t { };
empty_t foo2(empty_t* x) throw() {
return *x;
}
When I do a diff between the assembly generated for test.cc by 4.4.3 and 4.5.0
I get the following:
gcc443:
xorl %eax,%ea
--- Comment #3 from zsojka at seznam dot cz 2010-04-20 00:56 ---
I can't reproduce it anymore in r158225 and r158486
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43695
--- Comment #12 from navin dot kumar at gmail dot com 2010-04-20 00:51
---
(In reply to comment #11)
> It seems okay - at -O3 gcc 4.5.0 is correctly avoiding the memory copy. This
> used to happen at the default optimization for gcc 4.4.2, but that's fine.
> I'm
> closing the bug.
>
--- Comment #13 from justinmattock at gmail dot com 2010-04-20 00:17
---
Created an attachment (id=20430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20430&action=view)
early debugging via ohci1394_dma
dmesg of crash with init
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #12 from justinmattock at gmail dot com 2010-04-20 00:16
---
below is after compiling the kernel with 4.6.0 and running it
I can verify through using another machine(both are iMac9,1's) that the crash
only occurs with the machine with gcc 4.6.0
(I'll attach just in case)
k
--- Comment #11 from navin dot kumar at gmail dot com 2010-04-20 00:11
---
It seems okay - at -O3 gcc 4.5.0 is correctly avoiding the memory copy. This
used to happen at the default optimization for gcc 4.4.2, but that's fine. I'm
closing the bug.
--
navin dot kumar at gmail dot co
--- Comment #2 from patrick at motec dot com dot au 2010-04-20 00:02
---
Happens while linking my program.
Where in libc are they intended to live? Looking through the source it looks
like they may be part of libgcc.a but for powerpc-eabispe they aren't built.
--
http://gcc.gnu.or
--- Comment #3 from sje at cup dot hp dot com 2010-04-20 00:01 ---
Any ideas on how to fix the compiler? The best idea I could come up with was
to check each basic block to see if there are any conditional sets of predicate
registers in it and add pred.rel.mutex lines for those register
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-20 00:00 ---
Those functions are part of the ABI and should be provided by your libc.
Does this error happen while you are linking your program or while building
GCC?
--
pinskia at gcc dot gnu dot org changed:
Wha
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-19 23:57 ---
And tanhl is a GCC issue how? It is part of glibc and not GCC so please report
it to them.
Plus it works for me with:
libc version 2.7
libc release stable
On Debian 5.0.
--
http://gcc.gnu.org/bugzilla/show_bug
After migrating to gcc 4.5.0 my build is reporting these kinds of errors at
link time:
undefined reference to `_savegpr_31'
undefined reference to `_restgpr_31_x'
gcc 4.4.3 didn't emit _savegpr_* _restgpr_* etc. symbols when configured this
way.
powerpc-eabispe-gcc -v
Using built-in specs.
COLLE
--- Comment #10 from navin dot kumar at gmail dot com 2010-04-19 23:44
---
Wolfgang,
The opening post was a bad example, and it unfortunately is drawing attention.
I agree, it is invalid code for deferencing a NULL pointer. However, please
see my other posts, detailing how the actual
--- Comment #3 from tomdean at speakeasy dot org 2010-04-19 23:33 ---
Subject: Re: Tanh Returns Incorrect Value
On Mon, 2010-04-19 at 22:56 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-19 22:56
> ---
> That is be
--- Comment #2 from wilson at gcc dot gnu dot org 2010-04-19 23:28 ---
gcc-c.torture/compiler/920625-1.c would also be failing for the same reason,
except it has dg-prune-output hacks to discard the assembler warnings. We
should fix the IA-64 compiler, and then eliminate these dg-prune-
I originally posted this to the gcc mailing list, and then apparently forgot
about it, so I'm reporting it as a bug before I forget again. This bug report
is a copy of the original message.
http://gcc.gnu.org/ml/gcc/2008-04/msg00336.html
This testcase extracted from libgcc2.c
int
sub (int i)
{
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-19 23:00 ---
Related to PR 5650
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43803
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-19 22:57 ---
Here is the fixed up C testcase:
#include
#include
#include
#define _GNU_SOURCE
#include
#include
int main (int argc, char **argv)
{
long double complex arg = 1 + _Complex_I;
long double complex s, c, r, t;
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-19 22:56 ---
That is because you are using the double version of ctanh rather than the long
double version for the C case.
Changing the C testcase to use ctanhl and you get the same value for the C/C++
cases.
--
pinskia at g
--- Comment #11 from justinmattock at gmail dot com 2010-04-19 22:40
---
Subject: Re: kernel/rtmutex.c:1138:1: internal
compiler error: in cgraph_decide_inlining_of_small_functions, at
ipa-inline.c:1009
On 04/19/2010 02:07 PM, hjl dot tools at gmail dot com wrote:
> --- Comment #
--- Comment #9 from bangerth at gmail dot com 2010-04-19 22:18 ---
Dereferencing the null pointer invokes undefined behavior, independent on
whether the type of the dereferenced pointer is an empty class or not.
Typically, dereferencing NULL results in a trap. GCC simply preserves
this b
Tested revisions:
r158486 - fail
r158150 - fail
4.5 r158486 - OK
$ binary-158486-lto-fortran/bin/gfortran -fipa-reference -fschedule-insns
-fstrict-aliasing gcc/testsuite/gfortran.dg/alloc_comp_assign_3.f90 && ./a.out
Segmentation fault
$ binary-158486-lto-fortran/bin/gfortran -fipa-reference -fsc
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-19 21:51 ---
Subject: Bug 43339
Author: jakub
Date: Mon Apr 19 21:51:28 2010
New Revision: 158528
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158528
Log:
PR fortran/43339
* openmp.c (gfc_resolve_do_itera
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-19 21:50 ---
Subject: Bug 43337
Author: jakub
Date: Mon Apr 19 21:50:16 2010
New Revision: 158527
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158527
Log:
PR middle-end/43337
* tree-nested.c (convert_nonl
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-19 21:39 ---
Removing -O2 is never a proper work-around anyway. This should just work.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #21 from janus at gcc dot gnu dot org 2010-04-19 21:34 ---
(In reply to comment #20)
> Created an attachment (id=20429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20429&action=view) [edit]
> A provisional fix for the PR
Yes, the following parts are approved (they'r
--- Comment #1 from sje at cup dot hp dot com 2010-04-19 21:30 ---
/var/tmp//ccGMk41W.s: Assembler messages:
/var/tmp//ccGMk41W.s:201: Warning: Use of 'mov' may violate WAW dependency
'GR%, % in 1 - 127' (impliedf), specific resource number is 18
/var/tmp//ccGMk41W.s:201: Warning: Only t
--- Comment #20 from pault at gcc dot gnu dot org 2010-04-19 21:16 ---
Created an attachment (id=20429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20429&action=view)
A provisional fix for the PR
This needs cleaning up and FAILUREs of the gfc_resolve_expr's need dealing
with.
O
--- Comment #1 from michael at walle dot cc 2010-04-19 21:13 ---
Created an attachment (id=20428)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20428&action=view)
timer_list intermediate file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43807
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
http:
Compiling the attached file with debugging and optimization turned on causes an
infinite loop.
How-To-Repeat:
lm32-elf-gcc -O2 -c timer_list.i
--
Summary: lm32-elf infinite loop
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: c
--- Comment #10 from hjl dot tools at gmail dot com 2010-04-19 21:07
---
It may be caused revision 158278:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00382.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from dodji at gcc dot gnu dot org 2010-04-19 20:57 ---
I am testing a patch ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43800
--- Comment #9 from justinmattock at gmail dot com 2010-04-19 20:48 ---
Subject: Re: kernel/rtmutex.c:1138:1: internal
compiler error: in cgraph_decide_inlining_of_small_functions, at
ipa-inline.c:1009
On 04/19/2010 01:25 PM, falk at debian dot org wrote:
> --- Comment #8 from fal
--- Comment #9 from roman at binarylife dot net 2010-04-19 20:46 ---
The 4.5 branch works for me if patched this way.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43783
--- Comment #2 from philpem at philpem dot me dot uk 2010-04-19 20:33
---
Admittedly removing -O2 does fix the ICE in this file, however a different
source file (mm/filemap.c) causes a gcc ICE when it isn't built with -O2:
mm/filemap.c: In function do_generic_file_read:
mm/filemap.c:
--- Comment #1 from michael at zanyblue dot com 2010-04-19 20:33 ---
Created an attachment (id=20427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20427&action=view)
Ada sources suitable for "gnatchop"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43806
A source compilation generated the follow boxed error:
+===GNAT BUG DETECTED==+
| 4.5.0 (i686-pc-linux-gnu) GCC error: |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:319 |
| Error dete
--- Comment #1 from philpem at philpem dot me dot uk 2010-04-19 20:27
---
Created an attachment (id=20426)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20426&action=view)
timerfd intermediate file
.i file, requested per bug reporting guidelines
--
http://gcc.gnu.org/bugzill
--- Comment #1 from fabien dot chene at gmail dot com 2010-04-19 20:27
---
hmm, not sure this is invalid. This is the same than
struct A { int const i; };
void f() { new A() }
(Nevertheless, commeau doesn't compile both cases.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43803
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
Host: x86_64, Ubuntu Linux 9.10
Target: lm32-elf
GCC 4.5.0
../configure --prefix=/opt/lm32 --target=lm32-elf --enable-languages=c,c++
--with-newlib --enable-sjlj-exceptions
As reported on the Milkymist mailing list, gcc-4.5.0 is unable to build the
Milkymist branch of the Linux kernel (http://git
--- Comment #8 from falk at debian dot org 2010-04-19 20:25 ---
Confirmed with current 4.6 on x86-64, here is a testcase:
int owner();
int clear();
static void fixup() {
clear();
}
inline __attribute__ ((always_inline))
void slowtrylock(void) {
if (owner())
fixup();
}
v
--- Comment #2 from schwab at linux-m68k dot org 2010-04-19 20:14 ---
Created an attachment (id=20425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20425&action=view)
Reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-19 20:13 ---
Note that the patch in comment #7 fixes the test in comment #3 when the 'type
t_string' block is uncommented. But there is still a "Segmentation fault" when
the line
! procedure(string_to_char),pointer :: char2
--- Comment #1 from schwab at linux-m68k dot org 2010-04-19 20:13 ---
Created an attachment (id=20424)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20424&action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
$ gcc/xgcc -Bgcc/ -O2 -fpic -S memusage.i
memusage.c: In function me:
memusage.c:311:1: error: insn does not satisfy its constraints:
(insn 342 136 137 10 memusage.c:253 (set (reg/f:SI 2 %d2 [137])
(const:SI (unspec:SI [
(symbol_ref:SI ("start_sp") [flags 0x1a] )
another case where GCC/g++ accepts invalid code.
A::i should be initialized event if it is created via a temporary.
struct A
{
int const i;
}
void f()
{
A();
}
mine ...
--
Summary: uninitialized const member wrongly accepted using a
temporary
Prod
--- Comment #4 from fabien dot chene at gmail dot com 2010-04-19 20:03
---
mine ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
--- Comment #7 from justinmattock at gmail dot com 2010-04-19 19:55 ---
here you go:
head kernel/.rtmutex.o.cmd
cmd_kernel/rtmutex.o := gcc -Wp,-MD,kernel/.rtmutex.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include
-I/home/kernel/2.6.35/arch/x86/include -Iinclu
--- Comment #6 from hjl dot tools at gmail dot com 2010-04-19 19:51 ---
(In reply to comment #4)
> Created an attachment (id=20419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20419&action=view) [edit]
>
Please show the output of
# head kernel/.rtmutex.o.cmd
--
http://gcc
--- Comment #5 from justinmattock at gmail dot com 2010-04-19 19:43 ---
o.k. I got the kernel to compile with:
OPTIMIZE_INLINING [=y]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-19 19:28 ---
The 2.5 wording has been very vague, see
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01150.html
and
http://openmp.org/pipermail/omp/2005/000353.html
but it is true that the 3.0 wording is no longer that ambiguous.
-
--- Comment #14 from pinskia at gmail dot com 2010-04-19 19:11 ---
Subject: Re: GCC ICE on optimize attribute
Sent from my iPhone
On Apr 19, 2010, at 12:02 AM, "jakub at gcc dot gnu dot org"
wrote:
>
>
> --- Comment #11 from jakub at gcc dot gnu dot org 2010-04-19
> 07:02 -
Sent from my iPhone
On Apr 19, 2010, at 12:02 AM, "jakub at gcc dot gnu dot org" > wrote:
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-19
07:02 ---
This change broke building wine on x86-64.
There was already a bug filed for this and a patch was committed today
--- Comment #18 from pault at gcc dot gnu dot org 2010-04-19 18:48 ---
(In reply to comment #16)
I sort of doubt it. The problem arises because mio_symbol crashes in writing
the character length of the procedure symbol:
Breakpoint 1, mio_symbol (sym=0x9d02370)
at ../../fortran-dev/
--- Comment #17 from janus at gcc dot gnu dot org 2010-04-19 18:47 ---
(In reply to comment #16)
> I think the culprit is:
>
> Date: Sat Jul 25 11:56:35 2009
> New Revision: 150078
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150078
Close, but not quite :)
It's actually r15
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-19 18:46 ---
Created an attachment (id=20423)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20423&action=view)
fix PR43797
sorry, first version of the patch had a hunk unrelated to this PR.
--
iains at gcc dot gnu dot or
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-19 18:38 ---
Created an attachment (id=20422)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20422&action=view)
fix PR43797
I think we need to be consistent about adding the attributes and use a null
value to determine that
--- Comment #5 from iains at gcc dot gnu dot org 2010-04-19 18:26 ---
(In reply to comment #4)
> Subject: Re: Testsuite cannot detect duplicated
> error/warning messages
> In this case, I think this will work:
>
> /* { dg-bogus "foo bar" } */ /* { dg-warning "foo" } */
>
> no
--- Comment #6 from ubizjak at gmail dot com 2010-04-19 18:22 ---
(In reply to comment #4)
> I've recommended that the compile the code in different source files, although
> that is apparently complex for some reason. In any case, this seems to me
> like
> a clear bug: using MMX intri
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-19 18:03 ---
It is caused by revision 158483:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00589.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
--- Comment #4 from mikael at gcc dot gnu dot org 2010-04-19 17:58 ---
Probably changed in pr40823.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023
--- Comment #2 from tglek at mozilla dot com 2010-04-19 17:56 ---
(In reply to comment #1)
> -Wcoverage-mismatch isn't designed to cover this kind of errors. Are there
> source changes for the profile-use stage compared to the profile-generate
> stage?
>
No changes. Here is the line t
--- Comment #2 from mikael at gcc dot gnu dot org 2010-04-19 17:54 ---
*** This bug has been marked as a duplicate of 40823 ***
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from mikael at gcc dot gnu dot org 2010-04-19 17:54 ---
*** Bug 39991 has been marked as a duplicate of this bug. ***
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from lopezibanez at gmail dot com 2010-04-19 17:42 ---
Subject: Re: Testsuite cannot detect duplicated
error/warning messages
>
> is there another way?
In this case, I think this will work:
/* { dg-bogus "foo bar" } */ /* { dg-warning "foo" } */
no?
Cheers,
In c and c++, tanh returns a different incorrect value.
test-tanh.c: gcc test-tanh.c -o test-tanh-c-lm
test-tanh.cc: g++ test-tanh.cc -o test-tanh-cc
./test-tanh-c 711
libc version 2.10.1
libc release stable
arg= 7.11e+02 + 7.11e+02 * i
sinh (arg) = inf + inf * i
cosh (arg) = inf
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-19 17:24 ---
Gcc never handles MMX correctly. If you mix MMX and x87, gcc
may generate incorrect code due to missing emms.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from ian at airs dot com 2010-04-19 17:08 ---
Staying away from MMX registers is not an option here. This code is reduced
from some code in Chrome. Chrome is trying to provide several different
routines which do the same thing but which run on different processors. The
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-19 16:19 ---
(In reply to comment #2)
> The reason is the regexp that dejagnu uses to match the output
> /usr/share/dejagnu/dg.exp
...
> It would be nice if this were configurable or if we could override it.
yeah - I've just found
--- Comment #17 from redi at gcc dot gnu dot org 2010-04-19 16:15 ---
(In reply to comment #16)
>
> template
> inline pair::__type,
> typename __decay_and_strip<_T2>::__type>
> make_pair(const typename identity<_T1>::type& __x,
> const typename identity<_T2
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-19 16:13 ---
Can't reproduce this, neither with current 4.4 branch, nor 4.5, nor 4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43338
--- Comment #16 from redi at gcc dot gnu dot org 2010-04-19 16:13 ---
Understood, but I don't see any way to fix that code. std::make_pair has been
changed to handle rvalues, including deducing whether its arguments are lvalues
or rvalues.
By suppressing the type deduction you also sup
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-19 16:02 ---
Created an attachment (id=20421)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20421&action=view)
gcc46-pr43337.patch
Fix I'm going to test.
--
jakub at gcc dot gnu dot org changed:
What|Remo
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-19 16:02 ---
Another -O0 -fipa-* bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 200 matches
Mail list logo
