--- Comment #1 from ubizjak at gmail dot com 2008-03-19 06:58 ---
*** This bug has been marked as a duplicate of 35629 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #3 from ubizjak at gmail dot com 2008-03-19 06:58 ---
*** Bug 35636 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #10 from zuxy dot meng at gmail dot com 2008-03-19 06:43
---
Still, 4.3.0 can't recoginze %I64d
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
Gcc 4.4 revision 133314 has
FAIL: gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile "Found latch edge"
5
FAIL: gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile "Merged latch
edges" 2
FAIL: gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile "4 loops found" 2
FAIL: gcc.dg/tree-ssa/loo
struct {
unsigned int x:1;
} foo;
int bar = 0;
foo.x = bar != 0; // warning
foo.x = bar != 0 ? 1 : 0; // warning
if (bar != 0) foo.x = 1; else foo.x = 0; // no warnings, but too ugly..
--
Summary: -Wconversion problematic with bitfields
Product: gcc
Version: 4
--- Comment #1 from pinskia at gmail dot com 2008-03-19 06:10 ---
Subject: Re: New: [avr] result of char promotion comes out of CHAR_MIN/MAX
This code is only defined if char is unsigned which it is not on avr.
(It is unsigned on some targets like powerpc-Linux-gnu.
Sent from my iP
This code is only defined if char is unsigned which it is not on avr.
(It is unsigned on some targets like powerpc-Linux-gnu.
Sent from my iPhone
On Mar 18, 2008, at 22:42, "dmixm at marine dot febras dot ru" <[EMAIL PROTECTED]
> wrote:
/* The next program is aborted with avr-gcc 4.1.2, 4.
/* The next program is aborted with avr-gcc 4.1.2, 4.2.3, 4.3.0:
result of char promotion comes out of CHAR_MIN/MAX.
Options: -W -Wall -Os
Know to work:
3.3.6, 3.4.6 - good code
4.0.4 - correct, but not the best
4.1.2, 4.2.3, 4.3.0 - without optimization only
*/
#inc
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-03-19 05:40
---
Steve, also please replace the aborts in the test case and see what is really
happening. streamio_4.f90 is doing a large number of individual WRITEs in the
loop and your ktrace shows no failure of truncate. This
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-03-19 05:25
---
Since I do not have access to this system, can you try this:
Index: transfer.c
===
--- transfer.c (revision 133275)
+++ transfer.c (working copy)
--- Comment #2 from hp at gcc dot gnu dot org 2008-03-19 05:04 ---
You're updating the source and destination register but marking them only as
input in the asm. That's invalid. You trick GCC into believing that as it
hasn't changed, it can re-use the register with the source-address.
--- Comment #3 from hp at gcc dot gnu dot org 2008-03-19 04:43 ---
(In reply to comment #2)
> Hmmm, reverting Hans-Peter's patch does not fix the problem. Apologies
> to Hans-Peter for jumping the gun.
Apology accepted. FWIW, looking at your strace output and streamio_4.f90, it
seems th
--- Comment #2 from kargl at gcc dot gnu dot org 2008-03-19 04:09 ---
Hmmm, reverting Hans-Peter's patch does not fix the problem. Apologies
to Hans-Peter for jumping the gun.
Going back further in time, reverting r132512 fixes the problem with
streamio_4.f90, but
leads to
Running /us
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-03-19 03:46
---
*** Bug 35633 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-03-19 03:46
---
*** This bug has been marked as a duplicate of 35632 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
This commit:
2008-03-05 Hans-Peter Nilsson <[EMAIL PROTECTED]>
PR libfortran/35293
* io/unix.c (fd_truncate): Fold s->special_file case into
success case of ftruncate/chsize call instead of the failure case.
Make failure case actually return failure. Properly up
This commit:
2008-03-05 Hans-Peter Nilsson <[EMAIL PROTECTED]>
PR libfortran/35293
* io/unix.c (fd_truncate): Fold s->special_file case into
success case of ftruncate/chsize call instead of the failure case.
Make failure case actually return failure. Properly up
What's going on?
WARNING: program timed out.
FAIL: gfortran.dg/streamio_4.f90 -O0 execution test
--
Steve
--- Comment #2 from hp at gcc dot gnu dot org 2008-03-19 03:07 ---
My autotester says loop-25 fails in the same way for cris-elf, due to a patch
committed in the range 133311:133318.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
---
Someone has broken gfortran and/or the middle/backend.
FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans "transformed
loop" 1
--
Steve
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-19 02:57 ---
No, 4.1,4.2, and 4.3 are correct.
Read http://gcc.gnu.org/gcc-4.1/changes.html, the "ARM-style name-injection of
friend declarations is no longer the default. " section.
--
pinskia at gcc dot gnu dot org changed
The following example demonstrates the issue:
#include
#include
#define INLINE_FRIEND
class Outer {
enum InnerEnum {
Value0 = 0
};
typedef std::pair InnerPair;
friend bool operator==(const InnerPair& lhs, const InnerPair& rhs)
#ifdef INLINE_FRIEND
--- Comment #8 from amodra at bigpond dot net dot au 2008-03-19 01:17
---
Can you attach the object file that has the odd file name entry? I can't
reproduce this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
--- Comment #7 from amodra at bigpond dot net dot au 2008-03-19 00:54
---
Following up on comment #4, it was this part of Nick's patch that fixed the
--debug-dump=loc problem:
"Correct list of attributes which can reference a location list."
http://sourceware.org/ml/binutils/2007-11/msg
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-03-18 23:57
---
Namelist bugs are just a tradition. :) Assigning myself.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
this code does not compile with g++-4.3 (4.1 and 4.2 are able to compile it):
template
struct set
{};
struct derived:
public set
{
typedef set base;
void set(void) {}
};
[EMAIL PROTECTED]:~$ g++-4.3 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure l
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-18 22:02 ---
The problem is that we don't properly rewind properly for "nbshapa"; the parser
sees 'n'; it then try whether "NaN" matches. It checks the next character 'b'
and fails. The problem is that only 'b' and not 'nb' are pu
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-18 21:50 ---
Confirmed. Again a GCC 4.3.0/4.4.0 regression.
Seemingly caused between 2007-12-07-r130671 and 2007-12-10-r130736. Probably
caused by my NaN/INF patch (PR fortran/34319 - or, less likely, fortran/34404).
--
burnu
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|gcc.dg/tree-ssa/loop-25.c |[
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-18 21:32 ---
Confirmed. PREDICT_EXPR seems to force BBs unmerged and confuses loop
discovery.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
s 2
# of expected failures 166
# of untested testcases 35
# of unsupported tests 269
/home/jrp/build/gcc/xgcc version 4.4.0 20080318 (experimental) (GCC)
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure -v --enable-languages=c,c++,fo
--- Comment #11 from pluto at agmk dot net 2008-03-18 20:48 ---
(In reply to comment #10)
> Just add -fno-strict-aliasing.
>
just use __builtin_memcpy to avoid ugly casting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35621
--- Comment #10 from hjl dot tools at gmail dot com 2008-03-18 20:28
---
Just add -fno-strict-aliasing.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-03-18 20:24 ---
Why is this closed as won't fix. The testcase invokes undefined behavior and
should be fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from hjl dot tools at gmail dot com 2008-03-18 20:16 ---
Close it. We can reopen it if it fails at -O2.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #7 from ubizjak at gmail dot com 2008-03-18 20:12 ---
(In reply to comment #3)
> Actually it looks like all the ssse3-*.c testcase violate C aliasing rules.
I can confirm this, the test works OK with -fno-strict-aliasing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #4 from uros at gcc dot gnu dot org 2008-03-18 20:01 ---
Subject: Bug 35504
Author: uros
Date: Tue Mar 18 20:00:12 2008
New Revision: 133324
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133324
Log:
PR target/35504
* config/i386/i386.c (x86_this_para
I built gmp-4.2.2:
./configure --prefix=/opt/pkg/gmp-4.2.2
make
make install
And mpfr-2.3.1:
./configure --prefix=/opt/pkg/mpfr-2.3.1 --with-gmp=/opt/pkg/gmp-4.2.2/
--with-gmp-build=/opt/src/gmp-4.2.2/
make
make install
Oh the compiler I'm trying to install 4.3.0 (as well as gmp and mpfr) with:
T
Hello, It's the code:
http://www.nabble.com/file/p16128572/1.c 1.c
Try enter the number 0010 (number then), 00010, etc.. and see the bizarre
output..
Thanks..
--
View this message in context:
http://www.nabble.com/Works-on-dev-c..-tp16128572p16128572.html
Sent from the gcc - bugs mailing lis
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-18 17:28 ---
And the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35617
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-18 17:24 ---
Subject: Bug 35593
Author: rguenth
Date: Tue Mar 18 17:23:35 2008
New Revision: 133318
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133318
Log:
2008-03-18 Richard Guenther <[EMAIL PROTECTED]>
Ba
--- Comment #12 from tromey at gcc dot gnu dot org 2008-03-18 17:03 ---
I agree we should probably change ecj1's interpretation of -Wall.
But, ecj1 can't be part of gcc. That was already decided.
I believe the installation instructions have information on what
to download so that gcj w
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-18 16:53 ---
While this is a regression the underlying problem was latent and thus this
should be an enhacement report. But I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from deuling at de dot ibm dot com 2008-03-18 16:52 ---
./readelf --debug-dump=line give
for gfortran 4.1.2:
The Directory Table:
fortran
The File Name Table:
EntryÂDir····Time···Size···Name
1····1······0······0·····
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-18 16:19 ---
This is a dup of bug 33927 and 33790 which both have the same example as below
but are talking about different passes :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35626
Hi: The following program fails to read the namelist file below.
test program:
program test
implicit none
LOGICAL :: nlco(200) ! (1:nbeam)
REAL*8 :: xlbtna(200) ! (1:nbeam)
NAMELIST/nbdrive_naml/ nlco,xlbtna
INTEGER :: nbshapa(200) ! (1:nbeam)
NAMELIST/nbdrive_naml/ nbshapa
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org
|dot org
--- Comment #15 from matz at gcc dot gnu dot org 2008-03-18 15:37 ---
We can either force expanding the call address before the arguments (if
it overlaps with them) or simply validate the thing after the fact.
Validating seems a bit easier (and is in line with what is done already for
t
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-03-18 15:31
---
Similar case that SCCVN could also handle (store_ccp and DOM handle this):
int G;
void __attribute__((noinline))
foo (int i)
{
if (i > 0)
G = 3;
else
G = 3;
if (G != 3)
link_error ();
}
--- Comment #14 from ubizjak at gmail dot com 2008-03-18 15:30 ---
(In reply to comment #12)
> Uros: the problem isn't cse. It's already expand which creates broken code
> (it reads from and writes to (mem (plus (virtual-incoming-regs) (4)).
> But it does that only because the input tre
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-03-18 15:25
---
Actually the trees are correct, just the dumping of function names in call
exprs
is "interesting". Still expand is the primary suspect here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #12 from matz at gcc dot gnu dot org 2008-03-18 15:03 ---
Uros: the problem isn't cse. It's already expand which creates broken code
(it reads from and writes to (mem (plus (virtual-incoming-regs) (4)).
But it does that only because the input tree is completely wrong (TER br
--- Comment #2 from chris at bubblescope dot net 2008-03-18 15:02 ---
#include
#include
using namespace std;
int main(void)
{
vector > v;
}
Runs fine here, using:
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with: ../gcc/configure --enable-languages=c,c++
--pre
--- Comment #11 from ubizjak at gmail dot com 2008-03-18 15:01 ---
cse1 pass somehow figures out that:
(insn 11 10 12 2 function.c:5 (set (reg/f:SI 61)
(mem/s/f/c:SI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [4 data.listener+0 S4 A32])) 41 {*movsi_1}
(nil
--- Comment #10 from matz at gcc dot gnu dot org 2008-03-18 14:55 ---
The tree dumps already look wrong. from .130t.final_cleanup:
function_calling_listener (data)
{
:
data (data.a, data.c, data.d) [tail call];
return;
}
Note how the function pointer is replaced with the whole "da
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-18 14:53 ---
The stack modifications before the sibcall look indeed interesting. Micha,
maybe you want to poke into this somewhat?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #8 from ubizjak at gmail dot com 2008-03-18 14:45 ---
It works when function.c is compiled with -O2 -fno-optimize-sibling-calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #7 from ubizjak at gmail dot com 2008-03-18 14:34 ---
asm dump with GCC: (GNU) 4.4.0 20080318 (experimental) and -O2
-fomit-frame-pointer:
function_calling_listener:
movl20(%esp), %eax # data.d, data.d
movl16(%esp), %ecx # data.c, data.c
--- Comment #5 from deuling at de dot ibm dot com 2008-03-18 13:43 ---
Hi,
I build binutils from head and you're right. This issue is fixed:
[EMAIL PROTECTED] binutils]$ ./readelf --debug-dump=loc ~/fortran/neg_array
Contents of the .debug_loc section:
Offset BeginEnd
--- Comment #7 from jakub at gcc dot gnu dot org 2008-03-18 12:41 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2008-03-18 12:32 ---
Subject: Bug 35611
Author: jakub
Date: Tue Mar 18 12:31:28 2008
New Revision: 133310
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133310
Log:
PR middle-end/35611
* gimplify.c (gimplify_expr):
Compiling the following simple code sample with
-O3 on CELL spu produces very poor performing
code:
#include
typedef struct _vec_tri {
vector float x;
vector float y;
vector float z;
} vec_tri;
vec_tri add_tri(vec_tri a, vec_tri b)
{
vec_tri c;
c.x = spu_add(a.x, b.x);
c.y = spu_
--- Comment #5 from jakub at gcc dot gnu dot org 2008-03-18 12:21 ---
Subject: Bug 35611
Author: jakub
Date: Tue Mar 18 12:21:02 2008
New Revision: 133309
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133309
Log:
PR middle-end/35611
* gimplify.c (gimplify_expr):
--- Comment #4 from jakub at gcc dot gnu dot org 2008-03-18 11:14 ---
Seems OMP_ATOMIC_LOAD isn't properly regimplified and so &i in TREE_OPERAND
(omp_atomic_load, 1) isn't replaced with .omp_data_i->i. For targets with
sync builtins this doesn't matter, as expand_omp_atomic for them ru
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-18 10:51 ---
This looks like a target issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #3 from jakub at gcc dot gnu dot org 2008-03-18 09:57 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from jakub at gcc dot gnu dot org 2008-03-18 09:55 ---
Subject: Bug 35625
Author: jakub
Date: Tue Mar 18 09:55:09 2008
New Revision: 133307
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133307
Log:
PR libgomp/35625
* iter.c (gomp_iter_guided_next_
--- Comment #1 from jakub at gcc dot gnu dot org 2008-03-18 09:55 ---
Subject: Bug 35625
Author: jakub
Date: Tue Mar 18 09:54:21 2008
New Revision: 133306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133306
Log:
PR libgomp/35625
* iter.c (gomp_iter_guided_next_
--- Comment #1 from rurality dot wq at gmail dot com 2008-03-18 09:29
---
Created an attachment (id=15341)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15341&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35624
int
main (void)
{
#pragma omp parallel
{
#pragma omp for schedule (guided, 10)
for (int i = 0; i < 1826; i += 10)
;
#pragma omp for schedule (guided, 10)
for (int i = 0; i > -1826; i -= 10)
;
}
return 0;
}
hangs - after going through all iterations keeps ca
command is as below.
arm-elf-gcc -v -save-temps -O2 -ffreestanding -c -msoft-float -nostdinc test.c
Using built-in specs.
Target: arm-elf
Configured with: ./configure --target=arm-elf
--prefix=/rdisk1/users/wangqiang/tool-chain --enable-interwork
--enable-multilib --with-float=soft --enable-langu
--- Comment #5 from J dot Gorka at osmosys dot tv 2008-03-18 08:17 ---
All is fine. My friend copy that program from here, compile on gcc-4.3 and give
me result that is in comment #3 But ok, i copy one more time what is in
function.h file:
typedef void (*listener_fun)(
int a
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-18 08:01 ---
Can you include the contents of function.h, it seems to be missing ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #3 from J dot Gorka at osmosys dot tv 2008-03-18 07:57 ---
Ok. Now version 4.3.0 from Debian. The same problem
gcc-4.3 --version
gcc-4.3 (Debian 4.3.0-1) 4.3.1 20080309 (prerelease)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source f
78 matches
Mail list logo
