--- Comment #10 from carrot at google dot com 2010-01-11 06:47 ---
(In reply to comment #9)
> With "GCC: (GNU) 4.5.0 20100108 (experimental) [trunk revision 155731]" and my
> patch for bug 20070 applied, I get the following code:
>
> iterate:
> push{lr}
> ldr r3,
--- Comment #19 from pault at gcc dot gnu dot org 2010-01-11 06:14 ---
Created an attachment (id=19535)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19535&action=view)
Fix and testcase for the PR
This will be submitted to the list tonight after checking that other
transformationa
--- Comment #5 from pzhao at gcc dot gnu dot org 2010-01-11 04:28 ---
Subject: Bug 42467
Author: pzhao
Date: Mon Jan 11 04:28:36 2010
New Revision: 155801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155801
Log:
gcc/po/
2010-01-11 Joseph Myers
Shujing Zhao
--- Comment #2 from pzhao at gcc dot gnu dot org 2010-01-11 04:28 ---
Subject: Bug 42469
Author: pzhao
Date: Mon Jan 11 04:28:36 2010
New Revision: 155801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155801
Log:
gcc/po/
2010-01-11 Joseph Myers
Shujing Zhao
--- Comment #1 from pearly dot zhao at oracle dot com 2010-01-11 03:33
---
Joseph S. Myers says
the computations of column widths for alignment in opts.c should be using
gcc_gettext_width rather than strlen and pointer subtraction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
The following is to test the translation of the help text that contains a tab
character.
When use characters whose width in columns is not the same as their length in
bytes to translate, regenerate gcc.pot and change the locale, the output of the
translated help text is not be aligned.
--
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-01-11 02:58
---
This patch, reverting only the change to interface.c, appears to fix the
problem. No other regressions in testsuite.
Index: interface.c
===
--- int
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-01-11 02:54
---
This patch appears to avoid the problem. I have not looked farther up the call
chain yet to see where passing the NULL in name2 should be avoided completely
for the test case.
Index: interface.c
=
--- Comment #2 from ian_harvey at bigpond dot com 2010-01-11 01:56 ---
Some primitive debugging: As directed by parse_contained, parsing and
subsequent processing of the use statement in other_proc (parse_progunit)
occurs prior to parsing of the add_b function and hence determination of
--- Comment #2 from davek at gcc dot gnu dot org 2010-01-11 00:23 ---
(In reply to comment #1)
> We should probably warn instead "function returning non-void declared with
> attribute noreturn".
>
I think not; I don't see why you should be obliged to change the prototype of a
function
--- Comment #2 from trifunovic at gcc dot gnu dot org 2010-01-10 23:48
---
Cannot reproduce on x86_64 nor on IA32.
--
trifunovic at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from hubicka at gcc dot gnu dot org 2010-01-10 23:42
---
Well, since we want to make more similar changes in foreseeable future, I would
prefer to see ipa-sra enabled in 4.5 and problems fixed. It is excercising
quite new type of transformations. In general I am not sur
--- Comment #2 from zsojka at seznam dot cz 2010-01-10 23:41 ---
Could be related to pr42642
--
zsojka at seznam dot cz changed:
What|Removed |Added
CC|
--- Comment #1 from trifunovic at gcc dot gnu dot org 2010-01-10 23:36
---
Cannot reproduce on x86_64 nor on IA32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41334
--- Comment #1 from zsojka at seznam dot cz 2010-01-10 23:33 ---
Created an attachment (id=19534)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19534&action=view)
reduced testcase
Command line:
g++ -O1 -fcompare-debug -funroll-loops -c pr42685.cpp
--
http://gcc.gnu.org/bugzil
Command line:
g++ -O1 -fcompare-debug -funroll-loops -c testcase.cpp
-fno-web helps even in the nonreduced testcase
Tested revisions:
r155777 - crash
r155680 - crash
r154830 - crash
r153685 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-155777-lto/bin/g++ -O1 -fcompare-debug
-funroll-loops -c testca
--- Comment #8 from steven at gcc dot gnu dot org 2010-01-10 23:31 ---
Subject: Bug 42621
Author: steven
Date: Sun Jan 10 23:31:30 2010
New Revision: 155796
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155796
Log:
PR rtl-optimization/42621
* bb-reorder.c (gate_
--- Comment #12 from matt at use dot net 2010-01-10 23:29 ---
Created an attachment (id=19533)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19533&action=view)
pre-processed output of the file that emitted the false positive using the
commandline mentioned in my comment
--
htt
--- Comment #1 from ian_harvey at bigpond dot com 2010-01-10 23:21 ---
Created an attachment (id=19532)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19532&action=view)
Example source that causes the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42684
An internal compiler error (seg fault in gfc_get_default_type (symbol.c:226) -
due argument 'name' being passed in as a null ptr) occurs when two different
specific procedures for an operator (ie defining the same operator, but on
different derived types) are available, when one is available throug
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42681
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-10 22:55
---
IMHO we should go into-SSA for all functions before even starting with early
optimizations (that also avoids the funny SSA form mismatch during early
inlining of cycles). Of course that's for 4.6 as well.
Another
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-10 22:53 ---
The proper thing is to convert the pointer to an appropriate TYPE_PRECISION
signed type, do the arithmetic on it and after it convert it back to the
pointer type.
What does CLAST know about overflow issues here btw?
--- Comment #15 from hubicka at gcc dot gnu dot org 2010-01-10 22:51
---
In general requiring all changes to clone function body is bit expensive since
it involves copying of whole function (ipa-sra is one of more busy passes). It
is also somewhat difficult to implement with current PM
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-10 22:39 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #9 from igodard at pacbell dot net 2010-01-10 22:23 ---
Comeau gives this diagnostic:
"ComeauTest.c", line 1: error: use of a type with no linkage to declare a
variable
with linkage
enum {a, b, c} A = a;
^
This message give the true nature of the
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-10 22:08 ---
We should probably warn instead "function returning non-void declared with
attribute noreturn".
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-10 22:05 ---
Huh. lto1 should probably accept all frontend options but ignore most of them.
Or lto-wrapper should strip them.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mikpe at it dot uu dot se 2010-01-10 22:05 ---
(In reply to comment #3)
> Works for me with current 4.4 branch and trunk.
>
> I think this patch fixed it -
>
> http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00303.html -
> http://gcc.gnu.org/viewcvs?view=revision&re
--- Comment #8 from matt at use dot net 2010-01-10 22:04 ---
Created an attachment (id=19531)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19531&action=view)
pre-processed output of the file that emitted the false positive using the
commandline mentioned in my comment
--
http
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42676
--- Comment #11 from matt at use dot net 2010-01-10 22:01 ---
I get this same problem when compiling scummvm (http://scummvm.org) on Ubuntu
9.10/amd64 using the default GCC 4.4.1:
g++ -O1 -finline-small-functions -finline-functions
-Wp,-MMD,"engines/sci/.deps/console.d",-MQ,"engines/sci
--- Comment #14 from spop at gcc dot gnu dot org 2010-01-10 21:47 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from spop at gcc dot gnu dot org 2010-01-10 21:46 ---
Subject: Bug 42393
Author: spop
Date: Sun Jan 10 21:46:42 2010
New Revision: 155795
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155795
Log:
Fix PR42393.
2010-01-08 Sebastian Pop
PR middle-end/4
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-10 21:38
---
PR42678 has a not so confused audit trail but is about the same (remaining)
issue.
*** This bug has been marked as a duplicate of 42678 ***
--
rguenth at gcc dot gnu dot org changed:
What|Remov
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-10 21:38 ---
*** Bug 40409 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-10 21:37 ---
It can't be a regression. We never lower complex operations if you compile
with -Ox but link with -O0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from spop at gcc dot gnu dot org 2010-01-10 21:33 ---
The problem is in the code generation of the following CLAST:
if (7*T_6%8 == 0) {
...
}
where T_6 has a pointer type, and build refuses to construct a MULT_EXPR with a
pointer type.
I think that for this kind of expr
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-10 21:30 ---
You cannot wrap a function call inside a view-convert expr - at least the
gimplifier cannot deal with it by moving the view-convert to the LHS
which might not be possible in all cases anyway.
--
http://gcc.gnu.o
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42681
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36658
--- Comment #3 from ramana at gcc dot gnu dot org 2010-01-10 21:03 ---
Works for me with current 4.4 branch and trunk.
I think this patch fixed it -
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00303.html -
http://gcc.gnu.org/viewcvs?view=revision&revision=136215
I don't think thi
--- Comment #2 from spop at gcc dot gnu dot org 2010-01-10 20:52 ---
Mine.
I can reproduce the ICE in the Graphite branch with these flags:
-O1 -fgraphite-identity -fno-loop-block -fno-loop-interchange
-fno-loop-strip-mine
--
spop at gcc dot gnu dot org changed:
What
--- Comment #12 from spop at gcc dot gnu dot org 2010-01-10 20:46 ---
Subject: Bug 42393
Author: spop
Date: Sun Jan 10 20:46:28 2010
New Revision: 155793
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155793
Log:
Fix PR42393.
2010-01-08 Sebastian Pop
PR middle-end/4
--- Comment #4 from sje at gcc dot gnu dot org 2010-01-10 20:23 ---
Subject: Bug 37454
Author: sje
Date: Sun Jan 10 20:23:08 2010
New Revision: 155792
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155792
Log:
2010-01-10 Steve Ellcey
PR target/37454
* configu
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-10 19:39 ---
Fixed for 4.5 sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-10 19:37 ---
Subject: Bug 42667
Author: rguenth
Date: Sun Jan 10 19:37:45 2010
New Revision: 155791
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155791
Log:
2010-01-10 Richard Guenther
PR middle-end/42667
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-10 19:18
---
Well, these are two interesting data points: 1- The crash definitely is not
new, happens also with 4.2.4; 2- The same 4.4.x library, but ICC as C++
compiler, doesn't crash, maybe it's a random behavior, sure, b
--- Comment #2 from mjtruog at fastmail dot ca 2010-01-10 18:16 ---
I have been trying to make a simple test case for the ostringstream problem but
have not yet found one. However, I have been able to make a test case for the
crash when using std::cerr. The problems are probably relate
--- Comment #2 from ubizjak at gmail dot com 2010-01-10 17:42 ---
(In reply to comment #0)
> Furthermore, math-library function fminf()/fmaxf() (and fmin()/fmax() for
> double) would benefit from map to intrinsic minss/maxss processing. Now
> they
> cause math library calls, where
--- Comment #25 from hjl dot tools at gmail dot com 2010-01-10 17:15
---
(In reply to comment #24)
>
> Please show me how CLFS_CROSS_TOOLS gcc and binutils are configured.
>
Properly configured CLFS_CROSS_TOOLS gcc and binutils should
never use native header files/libraries even if t
--- Comment #24 from hjl dot tools at gmail dot com 2010-01-10 16:52
---
(In reply to comment #0)
> I'm using a gcc-4.4.1 cross-compiler to build another instance of gcc-4.4.1
> for
> the target system. make fails with the following error message:
>
>
> The configure command contain
--- Comment #16 from redi at gcc dot gnu dot org 2010-01-10 16:26 ---
Let's go for it, I check it in later today
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
The description of -march=i686/pentiumpro in the gcc manpage is:
i586, pentium
Intel Pentium CPU with no MMX support.
pentium-mmx
Intel PentiumMMX CPU based on Pentium core with MMX instruction set support.
pentiumpro
Intel PentiumPro CPU.
i686
Same as "generic", but when used as "march" op
--- Comment #1 from matti dot aarnio--gcc-bugs at zmailer dot org
2010-01-10 15:40 ---
Created an attachment (id=19530)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19530&action=view)
example code showing minss related unnecessary temp registers
Compile command: (on x86_64 ma
When scanning an array of float values for minima and maxima, among other
tasks, the compiler will correctly use "minss" instruction, however it does
this by:
movaps %samplereg,%tempreg
minss %minreg,%tempreg
movaps %tempreg,%minreg
This could be done simply as:
minss %samplereg
--- Comment #4 from dominiq at lps dot ens dot fr 2010-01-10 15:36 ---
The patch in comment #1 fixes the test in comment#0, bootstrapped, regtested,
and passed my tests.
I have split the tests in comment#2 and #3 in two:
module m
--- Comment #11 from andreast at gcc dot gnu dot org 2010-01-10 14:57
---
A plain gcc44 install does also work here. No patches needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
--- Comment #4 from dominiq at lps dot ens dot fr 2010-01-10 14:37 ---
Diff between the results of -fdump-tree-original with (good) and without (bad)
the patch in
http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html reverted:
[macbook] f90/bug% diff -up pr42680.f90.003t.original_good
pr4
--- Comment #46 from dominiq at lps dot ens dot fr 2010-01-10 14:25 ---
Created an attachment (id=19529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19529&action=view)
assembly for the good code
the good code: alignment of 'reduce' is not forced and the loop is vectorized
using
--- Comment #45 from dominiq at lps dot ens dot fr 2010-01-10 14:23 ---
The attachment in comment#44 is for the bad code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #44 from dominiq at lps dot ens dot fr 2010-01-10 14:21 ---
Created an attachment (id=19528)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19528&action=view)
s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-10 14:21
---
great ;) Of course I also wonder what is different in stand alone testing...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42639
--- Comment #1 from zsojka at seznam dot cz 2010-01-10 14:14 ---
Created an attachment (id=19527)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19527&action=view)
reduced testcase
Command line:
g++ -O1 -fgraphite-identity -c pr42681.cpp
--
http://gcc.gnu.org/bugzilla/show_bug
Command line:
g++ -O1 -fgraphite-identity -c testcase.cpp
Tested revisions:
r155777 - crash
r155680 - OK
r155256 - OK
r154830 - OK
Output:
$ /mnt/svn/gcc-trunk/binary-155777-lto/bin/g++ -O1 -fgraphite-identity -c
testcase.cpp
testcase.cpp: In function ‘void Init(A*)’:
testcase.cpp:9:6: internal c
--- Comment #15 from paolo dot carlini at oracle dot com 2010-01-10 13:46
---
Jon, what do you think, shall we go ahead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
--- Comment #43 from irar at il dot ibm dot com 2010-01-10 13:43 ---
Since -O2 -ftree-vectorize doesn't cause bad code, it has to be some other
optimization on top of vectorized code that causes the problem.
Bad code is generated when the alignment of 'reduce' is forced and the
reductio
--- Comment #20 from dominiq at lps dot ens dot fr 2010-01-10 13:33 ---
> Regressions on fortran-dev branch fixed.
This caused pr42680 .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
--- Comment #3 from dominiq at lps dot ens dot fr 2010-01-10 13:25 ---
Oops! the right link is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353#c19
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42680
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-10 13:23 ---
link http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html#c19
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42680
--- Comment #1 from dominiq at lps dot ens dot fr 2010-01-10 13:22 ---
Confirmed. The ICE disappears if the patch in
http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html is reverted (see
pr42353#c19 ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42680
--- Comment #23 from paolo dot carlini at oracle dot com 2010-01-10 12:17
---
I don't know what you mean exactly by "official", but certainly disabling the
build of the PCHs cannot hurt and cannot create any problem, beside the
testsuite running slower. Then, if you actually use PCHs in
--- Comment #22 from paolo dot carlini at oracle dot com 2010-01-10 12:16
---
I don't know what you mean exactly by "official", but certainly disabling the
build of the PCHs cannot hurt and cannot create any problem, beside the
testsuite running slower. Then, if you actually use PCHs in
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-10 11:57 ---
The following "fixes" (or hides?) the problem:
- Using "IMPORT" instead of "USE mod1" in the delete_m interface
- Reversing the order of the interfaces (assignment <-> delete_m) in mod2
* * *
Some debugging: che
--- Comment #21 from armand dot potter at free dot fr 2010-01-10 11:27
---
Build succeeds with the patch. Cannot test the just built compiler yet (have to
install the whole new system) but I will post the patch on clfs mailing list
for more testing (even if official instructions say to
--- Comment #14 from nospamname at web dot de 2010-01-10 11:13 ---
All GCC Versions after this Patch r146817 (Author: matz) have the Problem
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
Here is a better testprogram that show more exact what the code do, but this
generate with al
The test case attached to
http://gcc.gnu.org/ml/fortran/2010-01/msg1.html
fails on fortran-dev (svn rev.155786) with
gfcbug96d.f90: In function cg:
gfcbug96d.f90:77:0: internal compiler error: in gimplify_expr, at
gimplify.c:7176
No problem on a slightly older trunk.
--
Summ
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-10 10:42
---
At the very minimum we need a small reproducer.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-10 09:29 ---
Seemingly betwixt 2009-06-11-r148366 and 2009-06-15-r148480 (though with PR
36947 applied); I would guess it is due to PR 36947.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from dodji at gcc dot gnu dot org 2010-01-10 09:03 ---
Ah, thanks Paolo. Yes, I could reproduce it by launching make check-performance
and I think the candidate fix of 42634 fixes it for me here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42639
--- Comment #4 from rwild at gcc dot gnu dot org 2010-01-10 08:45 ---
(In reply to comment #2)
> Created an attachment (id=19518)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19518&action=view) [edit]
> patch to configure.ac. Pls run autoconf after applied this patch.
Your patch
--- Comment #5 from irar at il dot ibm dot com 2010-01-10 08:22 ---
In vector_alignment_reachable_p() we check if an access is packed using
contains_packed_reference(). For packed accesses we return false, meaning
alignment is unreachable and peeling cannot be used.
In the attached test
82 matches
Mail list logo
