--- Comment #10 from kargl at gcc dot gnu dot org 2010-06-25 06:29 ---
(In reply to comment #6)
> Subject: Re: [regression 4.4/4.5/4.6] ICE in
> resolve_equivalence()
>
> These previous patches don't seem to solve the problem:
> here is another reduced case that still fails in
--- Comment #9 from sebpop at gmail dot com 2010-06-25 06:24 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Fri, Jun 25, 2010 at 01:14, kargl at gcc dot gnu dot org
wrote:
> ... there is a 200 line difference in the location of your
> diff and my cl
--- Comment #8 from burnus at gcc dot gnu dot org 2010-06-25 06:20 ---
Comment 6 prints correctly the error that EQUIVALENCE is unexpected, but then
segfaults. Valgrind shows:
==11477== Invalid read of size 8
==11477==at 0x52B7BB: resolve_types (resolve.c:12544)
==11477==by 0x52
--- Comment #7 from kargl at gcc dot gnu dot org 2010-06-25 06:14 ---
(In reply to comment #5)
> Subject: Re: [regression 4.4/4.5/4.6] ICE in
> resolve_equivalence()
>
> On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org
> wrote:
> >
> >
> > Comment #1 from kargl at
--- Comment #6 from sebpop at gmail dot com 2010-06-25 06:07 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different place
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different place than before.
$ cat bug.f
CALL TRFWTM(JKT,XX,NX,Y,NIX,NORB2,1,TOL)
IF(DBUG.AND.NX.GT.0) THEN
EQUIVALENCE (DBUGME, DBUGME_STR)
--- Comment #5 from sebpop at gmail dot com 2010-06-25 05:49 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org
wrote:
>
>
> --- Comment #1 from kargl at gcc dot gnu dot org 2010-06-25 04:02
--- Comment #4 from sebpop at gmail dot com 2010-06-25 05:32 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Thu, Jun 24, 2010 at 23:42, kargl at gcc dot gnu dot org
wrote:
> The mangled Fortran code caught my eye. I'm actually wondering
> where Seb
Tweaking the order of library names might cause the mudflap runtime to assert.
$ cat foo.c
#include
#include
#include
static void *routine(void* arg)
{
pthread_t thr = pthread_self();
printf("foo %d\n", 1);
return NULL;
}
int main()
{
pthread_t thr;
pthread_create(&thr, NULL, routi
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-25 04:42 ---
(In reply to comment #2)
> Confirmed. I came up with the exact same patch and it does pass regression
> testing, of course. Collided when I tried to post this. :)
>
:)
The mangled Fortran code caught my eye. I'm ac
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-06-25 04:35
---
Confirmed. I came up with the exact same patch and it does pass regression
testing, of course. Collided when I tried to post this. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-25 04:02 ---
Index: resolve.c
===
--- resolve.c (revision 161047)
+++ resolve.c (working copy)
@@ -12506,6 +12506,9 @@ resolve_equivalence (gfc_equiv *eq)
int o
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-25 03:38 ---
It is caused by revision 152236:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00987.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
GCC trunk is ICEing in the fortran front-end while compiling this:
$ cat ./bug.f
165CONTINUE
EQUIVALENCE (CHECK, CHECK_STR)
DATA CHECK_STR/"CHECK "/
END
$ ./f951 bug.f
bug.f:2.72:
EQUIVALENCE (CHECK, CHECK_STR)
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-24 22:43 ---
Created an attachment (id=20999)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20999&action=view)
A patch
With this patch, I got
[...@gnu-6 divb]$ cat umod-4.c
int
foo (unsigned char x, unsigned char y)
{
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-24 22:41 ---
X86 backend has special support for
(zero_extract:SI (reg:M N) (const_int 8) (const_int 8))
If backend provides zero_extract, shouldn't we preserve it?
--
hjl dot tools at gmail dot com changed:
Wha
--- Comment #7 from sje at gcc dot gnu dot org 2010-06-24 22:31 ---
Subject: Bug 43283
Author: sje
Date: Thu Jun 24 22:31:23 2010
New Revision: 161342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161342
Log:
2010-06-24 Steve Ellcey
PR testsuite/43283
* gcc.
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-24 22:04 ---
can reproduce this anymore, closing as fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44629
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44628
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44625
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-24 21:58 ---
Fails also at -O2 -funroll-loops.
I can't see anything wrong with the tree-level code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-24 21:45 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.6.0
Priority|P3 |P2
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
http:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Priority|P3 |P4
http://gcc
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-24 21:40 ---
Seems to be confirmed at least.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44393
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-24 21:38 ---
If nobody tests and submits this patch the issue will be not fixed for 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44622
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44597
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44590
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44565
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44562
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44533
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44341
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44137
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44531
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44625
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-06-24 20:49
---
Both patches look ok. For the remaining issue it would probably work to
not copy unreachable blocks during unswitching?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-24 18:28 ---
Can you provide a full example that gives the error? And what is the exact
error that is being generated?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44658
--- Comment #6 from hjl at gcc dot gnu dot org 2010-06-24 18:21 ---
Subject: Bug 44588
Author: hjl
Date: Thu Jun 24 18:21:21 2010
New Revision: 161330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161330
Log:
Add missing testcases for PR 44588.
Added:
trunk/gcc/testsuite/g
--- Comment #5 from hjl at gcc dot gnu dot org 2010-06-24 18:20 ---
Subject: Bug 44588
Author: hjl
Date: Thu Jun 24 18:20:28 2010
New Revision: 161329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161329
Log:
Implement 8bit divmod patterns.
gcc/
2010-06-24 H.J. Lu
--- Comment #2 from gmcgrath at yahoo dot com 2010-06-24 18:16 ---
It is seen at the highest level in GCC using the ARM NEON intrinsic:
uint16x8_t vshll_n_u8(uint8x8_t a, __constrange(0,8) int b);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44658
--- Comment #2 from bugs at 59A2 dot org 2010-06-24 18:08 ---
Thanks, I have notified the author.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44657
--- Comment #32 from aoliva at gcc dot gnu dot org 2010-06-24 17:58 ---
I don't see how a bug reported in 2003 against 3.2 and marked as failing up to
4.0 could possibly be related in any way with VTA. Clearly that bug was fixed.
Sure, VTA does perform poorly with these testcases, but
After fixing PR 44588, I got
[...@gnu-6 divb]$ cat umod-4.c
int
foo (unsigned char x, unsigned char y)
{
return (x % y) != 0;
}
[...@gnu-6 divb]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -c -o umod-4.o umod-4.c
[...@gnu-6 divb]$ cat
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-24 17:56 ---
Nice! But to get anything merged to GCC you need first a copyright assignment.
Otherwise, we cannot even look at your code.
http://gcc.gnu.org/contribute.html#legal
For implementing this as a plugin, you do not need a
--- Comment #23 from jakub at gcc dot gnu dot org 2010-06-24 17:48 ---
Subject: Bug 44492
Author: jakub
Date: Thu Jun 24 17:48:16 2010
New Revision: 161328
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161328
Log:
PR middle-end/44492
* recog.h (struct recog_data
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-24 17:34 ---
If the assembler is choping on it, please report it to binutils:
http://sourceware.org/bugzilla . GCC is not the assembler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44658
This is really a reopen of bug #41196
vshll, q3, d7, #0
is valid but the compiler and assembler choke on it and/or intrinsic. I assume
that is because the fix from #41196 tests for shifts greater than 0. However,
the zero shift is valid and needed for cheap precision expansion (i.e., vmovl).
Some impressive code-completion features have been implemented as part of
GCCSense, providing accurate editor-agnostic code completion.
http://cx4a.org/software/gccsense/
This required some GCC modifications, and thus requires a customized compiler.
It would be very useful if these modifications
--- Comment #13 from jakub at gcc dot gnu dot org 2010-06-24 16:47 ---
For the last issue, perhaps doing delete_unreachable_blocks in between the
levels wouldn't work too well, loops would need to be discovered again etc.
Maybe we can just do something similar to find_unreachable_blocks
--- Comment #12 from jakub at gcc dot gnu dot org 2010-06-24 16:24 ---
Created an attachment (id=20998)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20998&action=view)
level-opt.patch
When we reach the max-unswitch-level param, the function returns immediately,
which means the co
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-24 16:21 ---
Created an attachment (id=20997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20997&action=view)
unswitch-tuplification.patch
While the validity of the testcase is questionable, what unswitching does looks
cer
For gcc.dg/tree-ssa/loadpre6.c we see at FRE time
# PT = { HEAP.9 } (glob)
# USE = anything
# CLB = anything
unexpanded_var_list.0_25 = malloc (16);
unexpanded_var_list = unexpanded_var_list.0_25;
# PT = nonlocal escaped { HEAP.9 HEAP.10 } (glob)
unexpanded_var_list.1_27 = unexpanded
--- Comment #11 from pault at gcc dot gnu dot org 2010-06-24 15:44 ---
(In reply to comment #10)
> Any backport ?
>
Ah yes, thanks, Mikael
I have drawn up a list of PRs for which I have fixes but have not made commits.
I'll try to get through them next week.
Paul
--
http://
--- Comment #5 from pault at gcc dot gnu dot org 2010-06-24 15:42 ---
(In reply to comment #4)
> (In reply to comment #2)
> > > OK for trunk with the usual embellishments of ChangeLogs and testcase?
> >
> > Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim that
> >
--- Comment #3 from pault at gcc dot gnu dot org 2010-06-24 15:31 ---
(In reply to comment #2)
> Paul, any reason not to commit the patch in comment #1?
>
No! I'll try to get to it on Sunday.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40158
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-24 15:31 ---
See comment #1.
check-fortran
already selects from the various dg.exps.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-24 15:22 ---
(In reply to comment #3)
> > It's supposed to specify the testsuite driver. That it does, but then
> > it forgets that it was supposed to run a specific test.
>
> dg.exp=files_to_test
>
> does it (without path).
Building released gcc-4.4.4 on ia64-hp-hpux11.23 and 11.31 fails:
echo timestamp > s-gtyp-input
build/gengtype /opt/build/gcc-4.4.4/gcc gtyp-input.list
gmake[3]: *** [s-gtype] Segmentation fault (core dumped)
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped t
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-24 14:52 ---
> It's supposed to specify the testsuite driver. That it does, but then
> it forgets that it was supposed to run a specific test.
dg.exp=files_to_test
does it (without path).
What is not clear to me is what 'gfor
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-24
13:50 ---
Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and
--traditional-cpp
> --- Comment #6 from jakub at gcc dot gnu dot org 2010-06-24 12:56 ---
> Can't reproduce on x86_64-linux (an
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org
|dot org
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-24 13:36 ---
(In reply to comment #1)
> Confirmed. Yet another bug or feature dilemma!-)
>
> Using
>
> make check-fortran RUNTESTFLAGS='dg.exp=data_invalid.f90'
>
> works for me. I don't know what "gfortran.dg/" is supposed t
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-24 13:31 ---
This looks like a bug in the source to me, certainly not a middle-end or
tree-optimization bug.
The
a_sp => matrix%local_data_sp
assignment when
matrix%local_data_sp
is uninitialized means you are copying uninitialize
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-24 13:24 ---
Confirmed. Yet another bug or feature dilemma!-)
Using
make check-fortran RUNTESTFLAGS='dg.exp=data_invalid.f90'
works for me. I don't know what "gfortran.dg/" is supposed to do.
--
http://gcc.gnu.org/bugzill
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-24 12:56 ---
Can't reproduce on x86_64-linux (and, #pragma redefine_extname seems to be
handled on all targets, not just Solaris).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
--- Comment #12 from sebastian dot huber at embedded-brains dot de
2010-06-24 12:49 ---
(In reply to comment #11)
[...]
> I'll get this and Bug 44647 done for 4.6.0
Please have a look at Bug 43863 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
--- Comment #6 from borntraeger at de dot ibm dot com 2010-06-24 12:35
---
HJ confirmed that the patch worked and Andreas applied the patch. So from my
point of view, the problem is fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44203
--- Comment #11 from redi at gcc dot gnu dot org 2010-06-24 12:21 ---
(In reply to comment #7)
>
> Is libstdc++-v3/doc/xml/manual/configure.xml the main source for
> documentation?
Yes, however as you don't have a copyright assignment in place, submitting
these patches might actually
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-24
12:20 ---
Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and
--traditional-cpp
> --- Comment #4 from jakub at gcc dot gnu dot org 2010-06-24 11:51 ---
> created. But, as this PR lacks a
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-24 12:03 ---
(In reply to comment #3)
> I think column 0 is correct for the start of all preprocessor directives.
But the #include does not start at column 0, so there is something wrong there.
We know that libcpp column informatio
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-24 11:58 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
When I do:
make check-fortran RUNTESTFLAGS='gfortran.dg/dg.exp=data_invalid.f90'
the entire gfortran.dg/dg.exp testsuite is run.
--
Summary: check-fortran / gfortran.dg/dg.exp ignores test
specification in RUNTESTFLAGS
Product: gcc
Version:
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-24 11:51 ---
note->type == 10 is:
*d = '\n';
/* A sentinel note that should never be processed. */
add_line_note (buffer, d + 1, '\n');
buffer->next_line = s + 1;
created. But, as this PR lacks a testcase (well, the testc
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-24 11:33 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-24 11:25 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-24 11:24 ---
Is this now fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44203
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-06-24 11:06
---
> The memory_reg_operand predicate checks this and fails if it is not a memory
> with a single reg, but apparently there is no constraint letter that would
> require the same. So, either we need to add a new cons
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-24 11:00 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-24 10:57 ---
The cas/casx insns only allow (mem (reg)) addressing:
(match_operand:I48MODE 1 "memory_reg_operand" "+m")
(match_operand:DI 1 "memory_reg_operand" "+m")
The memory_reg_operand predicate checks this and fails if it is
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-24 10:44 ---
Created an attachment (id=20996)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20996&action=view)
gcc46-pr44539.patch
This works too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44539
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-24 10:19
---
In general, regenerated files should not be posted at all, when submitting
patches / changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-24 10:13 ---
I would simply move the update_stmt call down to be called unconditionally
before returning. Setting changed to true isn't needed, as iterating
will not discover more things just because we remove a vop.
--
htt
--- Comment #9 from sebastian dot huber at embedded-brains dot de
2010-06-24 10:09 ---
Created an attachment (id=20995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20995&action=view)
Implementation, configure and documentation
Sorry, the config.h.in was missing.
--
sebastia
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-24 10:02
---
Jon, can you follow this one too?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-24 10:00
---
... to resolve as duplicate.
*** This bug has been marked as a duplicate of 40263 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-24 10:00
---
*** Bug 44653 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
1 - 100 of 114 matches
Mail list logo
