--- Comment #1 from linuxl4 at sohu dot com 2008-09-29 05:54 ---
Created an attachment (id=16423)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16423&action=view)
the preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37672
[~/build/libiberty]$gcc --version
gcc (GCC) 4.4.0 20080928 (experimental)
[~/build/libiberty]$gcc -c -O2 -fgraphite md5.c
/trunk/libiberty/md5.c: In function 'md5_process_block':
/trunk/libiberty/md5.c:271: internal compiler error: in scan_tree_for_params,
at graphite.c:1879
Pleas
--- Comment #1 from pinskia at gmail dot com 2008-09-29 02:56 ---
Subject: Re: New: can't use iostream library
Sent from my iPhone
On Sep 28, 2008, at 7:44 PM, "hadmanysons at gmail dot com"
<[EMAIL PROTECTED]
> wrote:
> Whenever I try to compile something using the iostream lib
Sent from my iPhone
On Sep 28, 2008, at 7:44 PM, "hadmanysons at gmail dot com" <[EMAIL PROTECTED]
> wrote:
Whenever I try to compile something using the iostream library, gcc
pumps out a
lot of errors. Here's the gcc -v -save-temps screen:
Using built-in specs.
Target: i386-redhat-linux
Whenever I try to compile something using the iostream library, gcc pumps out a
lot of errors. Here's the gcc -v -save-temps screen:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bu
--- Comment #2 from uleysky at gmail dot com 2008-09-29 02:07 ---
The priority must not be same. The only method to interact constructor function
with main is global variables. It is no reason to initialize global variables
after constructor function. Anyway,
Test ex_t __attribute__ ((i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-28 23:43 ---
*** Bug 34151 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-28 23:43 ---
Mark as a dup of bug 29693.
*** This bug has been marked as a duplicate of 29693 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-28 23:43 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-28 23:43 ---
*** Bug 37670 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-28 23:43 ---
*** This bug has been marked as a duplicate of 35703 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from ralphs at netwinder dot org 2008-09-28 23:41 ---
Created an attachment (id=16422)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16422&action=view)
unwind-dw2.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37670
Successfully built gcc 4.3.1 toolchain using 4.1.1
Cannot rebuild 4.3.1 under itself, see error message below.
Same problem occurs when trying to build 4.3.2.
Looks similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693 except:
- compiling for oabi not eabi
- building 4.3.x not 3.4.x
I wond
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-09-28 23:17
---
I came up with the same patch for the Altivec modes when doing the merge of the
PS3 compiler to a 4.3 based compiler.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-28 23:08 ---
Subject: Bug 37640
Author: pinskia
Date: Sun Sep 28 23:07:01 2008
New Revision: 140740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140740
Log:
2008-09-28 Andrew Pinski <[EMAIL PROTECTED]>
PR ta
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-28 23:07 ---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-28 22:52 ---
Fixed at least on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
K
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-28 22:50 ---
Subject: Bug 36891
Author: pinskia
Date: Sun Sep 28 22:48:48 2008
New Revision: 140738
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140738
Log:
2008-09-28 Andrew Pinski <[EMAIL PROTECTED]>
Ka
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-28 21:58 ---
On the trunk we get a slightly different ICE:
t.c: In function 'RRB':
t.c:4: internal compiler error: in gimple_assign_set_rhs1, at gimple.h:1755
Please submit a full bug report,
with preprocessed source if appropria
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-28 21:17 ---
Mine, as far as I can tell this never worked.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from dominiq at lps dot ens dot fr 2008-09-28 20:49 ---
With the patch in comment #6, gfortran.dg/transfer_array_intrinsic_4.f90 fails:
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90:16.8:
ia = TRANSFER (s1, (/ 0_4 /))
1
Error:
--- Comment #11 from pault at gcc dot gnu dot org 2008-09-28 20:38 ---
See http://gcc.gnu.org/ml/fortran/2008-09/msg00407.html
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 19:57 ---
We need the source to figure out what is going wrong here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37644
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 19:55 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 19:54 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #4 from pault at gcc dot gnu dot org 2008-09-28 19:54 ---
(In reply to comment #3)
> works correctly with e.g. ifort and xlf90, so worth fixing somehow.
>
Thomas' #2 is correct - see the present discussion on the list.
I think that we have to bite the bullet and change the
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 19:53 ---
C99 (7.19.6.1/6) says:
For d, i, o, u, x, and X conversions, if a precision is specified, the 0 flag
is ignored.
So the warning is correct.
>The '0' flag isn't actually ignored, and it shouldn't be anyway, so I thi
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-28 19:48 ---
Why don't I take it too? :-)
paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 19:43 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-28 19:41 ---
With checking enabled and a much older version of 4.3.0:
tree PRE : 196.08 (97%) usr 2.78 (74%) sys 276.77 (97%) wall
2434 kB (10%) ggc
While on the trunk we get:
tree PRE : 0.54 (
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-28 19:36 ---
The trunk does not have a compile time issue, even with checking enabled ...
The RA issue is unrelated.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyw
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-28 19:33 ---
Created an attachment (id=16421)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16421&action=view)
A tentative fix for this PR
This allows the testcase to compile and run correctly. I am now not sure if x
does n
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-28 19:33 ---
*** Bug 37659 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-28 19:33 ---
This is a normal RA issue with targets like x86 where the RA does not
understand how to move instructions around to get back the register ...
*** This bug has been marked as a duplicate of 27001 ***
--
pinskia a
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-28 19:29 ---
Reduced testcase:
typedef long unsigned int size_t;
extern __inline __attribute__ ((__always_inline__)) int __attribute__
((__nothrow__)) snprintf (char *__restrict __s, size_t __n, __const char
*__restrict __fmt, ..
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-28 19:03 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 18:57 ---
This works on the trunk at -O0 but fails at -O2.
I think this is undefined as the priority are the same.
You should use init_priority and set a priority for the constructor.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-28 18:43 ---
4.3 also produced the bad IR but 4.3's VRP did not ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-28 18:37 ---
Reduced testcase:
static int
func_18 (void)
{
return 1;
}
int func_37 (int p_38)
{
return (func_18 () >= 1 ^ (div_rhs (1) || 0) || 0);
}
--- CUT ---
Before VRP we have:
D.1584_5 = 1 ^ D.1583_4;
which is wron
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 18:23 ---
Reduced testcase:
int
func_99 (int p_100)
{
p_100 = 1 >= p_100;
int l_102 = -1885403717;
int l_108;
p_100 = p_100 + (p_100 != l_102 * l_102);
if (p_100)
func_50 ();
}
--- CUT ---
I think this comes dow
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-28 18:03 ---
Posted patch:
http://gcc.gnu.org/ml/fortran/2008-09/msg00443.html
Approved, but check in will probably deferred until 4.5 opens.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #27 from wbrana at gmail dot com 2008-09-28 18:00 ---
gcc 4.3.2, -march=core2 instead of -march=nocona
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST: Iterations/sec.
--- Comment #5 from gcc at spatium dot org 2008-09-28 17:27 ---
Subject: Re: [4.4 Regression] gcc-4.4-20080919 ada build failure
> What happens if you don't use profiledbootstrap but instead bootstrap?
I did make bootstrap in the very same directory and it built everything
okay. Howev
--- Comment #2 from simartin at gcc dot gnu dot org 2008-09-28 16:43
---
Patch submitted here:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01900.html
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-09-28 15:20
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-09-28 15:16
---
Subject: Bug 36575
Author: ebotcazou
Date: Sun Sep 28 15:15:16 2008
New Revision: 140736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140736
Log:
PR middle-end/36575
* fold-const (div_a
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-09-28 15:15
---
Subject: Bug 36575
Author: ebotcazou
Date: Sun Sep 28 15:13:52 2008
New Revision: 140735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140735
Log:
PR middle-end/36575
* fold-const (div_an
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-09-28 15:13
---
Subject: Bug 36575
Author: ebotcazou
Date: Sun Sep 28 15:12:07 2008
New Revision: 140734
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140734
Log:
PR middle-end/36575
* fold-const (div_an
--- Comment #5 from doko at gcc dot gnu dot org 2008-09-28 14:51 ---
Subject: Bug 37636
Author: doko
Date: Sun Sep 28 14:49:51 2008
New Revision: 140733
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140733
Log:
2008-09-28 Matthias Klose <[EMAIL PROTECTED]>
* PR libgc
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-28 11:57 ---
Don't know if the patch is OK, but the code is obviously doing something silly.
CC-ing ARM maintainer.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from kunzjacq at yahoo dot fr 2008-09-28 11:43 ---
Created an attachment (id=16420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16420&action=view)
changes against snapshot 20080926 in t-cygwing, t-cygwin and t-mingw32 to get
mingw32 bootstrap working again
--
--- Comment #1 from dcb314 at hotmail dot com 2008-09-28 10:57 ---
Created an attachment (id=16419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16419&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
I just tried to compile the Suse Linux package enlightenment-0.16.8.12-15 with
the new gcc version 4.4, snapshot dated 20080926.
gcc said
backgrounds.c: In function 'BackgroundGetUniqueString':
backgrounds.c:75: internal compiler error: Segmentation fault
Please submit a full bug report,
with pre
--- Comment #1 from martinwguy at yahoo dot it 2008-09-28 09:55 ---
Created an attachment (id=16418)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16418&action=view)
Aplies the "obvious" fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37668
Hi
I spotted this while trawling through the arm code generator: the code in the
NEG case has no effect. I assume the NEG case should return if the condition
matches; patch attached. It's still present in trunk.
case NEG:
if (TARGET_HARD_FLOAT && GET_MODE_CLASS (mode) == MODE_FLOAT)
--- Comment #7 from kunzjacq at yahoo dot fr 2008-09-28 09:48 ---
the above patch breaks libssp on mingw32:
make[2]: Entering directory `/e/mingw_build/build-gcc/mingw32/libssp'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2 " "CXXFLAGS=-g -O2 "
"CFLAGS_FOR_BUILD=-g -O2" "CFLAGS
--- Comment #12 from kunzjacq at yahoo dot fr 2008-09-28 08:11 ---
same for me on mingw, bootstrap fails with patch. I get:
/e/mingw_build/build-gcc/./gcc/xgcc -B/e/mingw_build/build-gcc/./gcc/
-L/e/mingw_build/build-gcc/mingw32/winsup/mingw -L/e/mingw_build/build
-gcc/mingw32/winsup/w3
--- Comment #9 from laurent at ient dot rwth-aachen dot de 2008-09-28
07:59 ---
(In reply to comment #8)
> Try
> #define inline inline __attribute__((always_inline))
> instead. The inline keyword changes linkage, so you have to keep it.
> If you keep having problems open a new bugrep
62 matches
Mail list logo
