/vol1/tmp/rwgk/gcc_trunk_140355_fc8_x86_64
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.0 20080914 (experimental) (GCC)
% cat boost_mpl_less.cpp
#include boost/mpl/less.hpp
% g++ -c boost_mpl_less.cpp
In file included from /usr/include/boost/mpl/aux_/numeric_op.hpp:22
: x86_64-unknown-linux-gnu
Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure
--prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_140355_fc8_x86_64
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.0 20080914 (experimental) (GCC)
% cat boost_mpl_less.cpp
#include boost/mpl
++,fortran
Thread model: posix
gcc version 4.4.0 20080914 (experimental) (GCC)
% cat boost_mpl_less.cpp
#include boost/mpl/less.hpp
% g++ -c boost_mpl_less.cpp
In file included from /usr/include/boost/mpl/aux_/numeric_op.hpp:22,
from /usr/include/boost/mpl/aux_
--- Comment #1 from irar at il dot ibm dot com 2008-09-14 07:00 ---
I think those loops are not supposed to get vectorized. E.g., in
gcc.target/i386/vectorize2.c the store statement b[i_14] = D.1579_6 is not
vectorizable because vector long int (the vector type of the statement taken
--- Comment #2 from pluto at agmk dot net 2008-09-14 07:06 ---
-rdynamic could be enabled by the --with-gnu-ld configure option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37454
--- Comment #6 from nm127 at freemail dot hu 2008-09-14 07:14 ---
(In reply to comment #5)
This is all expected, if you want a string constant to be in a different
section, you need to put there your self by using a variable.
So the __attribute__ __section__ modifier is not
--- Comment #2 from rwgk at yahoo dot com 2008-09-14 07:24 ---
What is on that line?
#elif BOOST_PP_ITERATION_DEPTH() == 1
If you don't have /usr/include/boost, you can get the entire boost
tree from here:
svn co https://svn.boost.org/svn/boost/trunk boost
Then simply compile
--- Comment #7 from brian at dessent dot net 2008-09-14 07:54 ---
Subject: Re: attribute section is not working with constant strings
If you want a struct containing a pointer to a string in a specified
section, then:
char str[] __attribute__ ((__section__(.xxx_section))) = foo;
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #5 from schwab at suse dot de 2008-09-14 08:08 ---
*** Bug 37518 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #3 from schwab at suse dot de 2008-09-14 08:08 ---
*** This bug has been marked as a duplicate of 36453 ***
--
schwab at suse dot de changed:
What|Removed |Added
When compiling the following (bad) code with gcc 4.4.0 20080912 I get an error
message.
int x __attribute__ ((__section__(1)));
int main() {
return 0;
}
The error message is:
test.c:2: error: section attribute not allowed for 'x'
The problem is really that the __section__ should have
--- Comment #12 from hubicka at ucw dot cz 2008-09-14 09:18 ---
Subject: Re: 7 Internal Compiler Errors when compiling OpenFOAM-1.5
Honza,
I may not be analyzing this correctly, but it looks like
cgraph_remove_unreachable_nodes() may be removing something that is not dead.
Is
--- Comment #13 from hubicka at ucw dot cz 2008-09-14 09:24 ---
Subject: Re: 7 Internal Compiler Errors when compiling OpenFOAM-1.5
Looking at the log, it seems to be another leak where multiple
declarations points to single struct function. This is of course quite
evil bug with
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-14 09:32 ---
I don't follow. For vectorize2.c we have
b[i] = lrint (a[i]);
where we should be able to vectorize this using lrint vectorization and
a scalar long - int conversion (which is a no-op on i686 and should be
--- Comment #1 from nm127 at freemail dot hu 2008-09-14 09:18 ---
Created an attachment (id=16317)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16317action=view)
add a new error message for attribute section parameter type check
This patch separates the type check of the
--- Comment #9 from domob at gcc dot gnu dot org 2008-09-14 09:59 ---
Subject: Bug 36214
Author: domob
Date: Sun Sep 14 09:57:50 2008
New Revision: 140358
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140358
Log:
2008-09-11 Daniel Kraft [EMAIL PROTECTED]
PR
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
--- Comment #10 from domob at gcc dot gnu dot org 2008-09-14 10:02 ---
Fixed for trunk (4.4) and 4.3.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
--- Comment #3 from irar at il dot ibm dot com 2008-09-14 10:04 ---
(In reply to comment #2)
I don't follow. For vectorize2.c we have
b[i] = lrint (a[i]);
where we should be able to vectorize this using lrint vectorization and
a scalar long - int conversion (which is a
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-14 10:09 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenther at suse dot de 2008-09-14 10:36 ---
Subject: Re: [4.4 Regression] Revision 140257 causes
vectorizer tests failures
On Sun, 14 Sep 2008, irar at il dot ibm dot com wrote:
--- Comment #3 from irar at il dot ibm dot com 2008-09-14 10:04 ---
--- Comment #2 from 9ugsa9j02 at sneakemail dot com 2008-09-14 11:17
---
Subject: Re: Useless instructions in member call
by pointer
pinskia at gcc dot gnu dot org gcc-bugzilla-at-gcc.gnu.org |Forums| wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-14 02:01
--- Comment #5 from irar at il dot ibm dot com 2008-09-14 12:05 ---
(In reply to comment #4)
For the 32bit case the problem is really the choice of the vector
type for the store (where is this decided on?). As the type of
b is int it should have chosen vector int instead of vector
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-09-14 12:11
---
See http://gcc.gnu.org/ml/fortran/2008-09/msg00259.html for start of patch and
request for comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
--- Comment #4 from pault at gcc dot gnu dot org 2008-09-14 12:13 ---
This is caused by my fix for the regression PR32526 and the fix for PR31494. I
completely overlooked the possibility that folk might CALL functions:-)
I have a prospective fix in gfc_match_call:2545, which is where
--- Comment #5 from aesok at gcc dot gnu dot org 2008-09-14 12:51 ---
Subject: Bug 24894
Author: aesok
Date: Sun Sep 14 12:50:10 2008
New Revision: 140360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360
Log:
PR target/19636
PR target/24894
PR
--- Comment #9 from aesok at gcc dot gnu dot org 2008-09-14 12:51 ---
Subject: Bug 31644
Author: aesok
Date: Sun Sep 14 12:50:10 2008
New Revision: 140360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360
Log:
PR target/19636
PR target/24894
PR
--- Comment #17 from aesok at gcc dot gnu dot org 2008-09-14 12:51 ---
Subject: Bug 31786
Author: aesok
Date: Sun Sep 14 12:50:10 2008
New Revision: 140360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360
Log:
PR target/19636
PR target/24894
PR
--- Comment #23 from aesok at gcc dot gnu dot org 2008-09-14 12:51 ---
Subject: Bug 19636
Author: aesok
Date: Sun Sep 14 12:50:10 2008
New Revision: 140360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360
Log:
PR target/19636
PR target/24894
PR
--- Comment #6 from rguenther at suse dot de 2008-09-14 12:53 ---
Subject: Re: [4.4 Regression] Revision 140257 causes
vectorizer tests failures
On Sun, 14 Sep 2008, irar at il dot ibm dot com wrote:
--- Comment #5 from irar at il dot ibm dot com 2008-09-14 12:05 ---
(In
--- Comment #1 from ubizjak at gmail dot com 2008-09-14 13:23 ---
Confirmed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Severity|normal
--- Comment #2 from ubizjak at gmail dot com 2008-09-14 13:29 ---
GCC now implements whole lot of vector conversions, including int--float and
int--double. See 24659.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-09-14 14:20 ---
I can't find a mention of -i8 in the gfortran
documentation. I wonder if it even should work...
Confirmed, the current behavior is at least inconsistent.
--
tkoenig at gcc dot gnu dot org changed:
-Wno-strict-aliasing -Wextra -Wno-unused-parameter
-Wold-style-cast -version -ftemplate-depth-40
GNU C++ (GCC) version 4.4.0 20080914 (experimental) (powerpc-ibm-aix5.3.0.0)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21), GMP version 4.2.1, MPFR version 2.2.1.
GGC
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-14 15:09 ---
I am not sure, but I seems to remember a discussion about the fact that -i8
could not be used and -fdefault-integer-8 has been chosen because -i has some
meaning after compilation (linker?). Does it ring some bell
--- Comment #15 from dje at gcc dot gnu dot org 2008-09-14 15:35 ---
Honza,
I think that your recent pt.c:tsubst_decl() fix coincidentally may have fixed
this as well. Tracing the ggc_alloc_stat() calls, struct function only appears
to be allocated once, but likely is copied when it
--- Comment #4 from rwild at gcc dot gnu dot org 2008-09-14 15:37 ---
FWIW, this happens inside libtool configure tests,
so I guess it is harmless inside gcc/.
Do you see this in other directories' configure outputs, too,
and if yes, can you post a little more context (esp. the 5 or so
--- Comment #5 from dominiq at lps dot ens dot fr 2008-09-14 16:12 ---
I have found it: http://gcc.gnu.org/ml/fortran/2005-03/msg00189.html
RFC: renaming -i8, -r8, and -d8
From: Steve Kargl sgk at troutmask dot apl dot washington dot edu
To: fortran at gcc dot gnu dot org
Date: Fri,
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-09-14 16:42
---
Created an attachment (id=16318)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16318action=view)
proposed patch
The problem here is that the parser matches a general expression and has to
check later that
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-14 16:51 ---
Yes, that's probably the best to get comments/reviews for your patch; if you
think it is already mature, CC [EMAIL PROTECTED], too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
--- Comment #16 from jorn dot amundsen at ntnu dot no 2008-09-14 17:11
---
(In reply to comment #15)
With 4.3.2, and by uncommenting a superfluous third party package, I am down at
4 ICE's. The makeChemkinReactions ICE is still present with 4.3.2, though. Now,
since cp/pt.c are
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-09-14 17:58
---
I see that I did not use RESOLVE_TAG in gfc_resolve_dt. Doing so resolves the
ICE issue. Then if we really want to accept this poorly written code, I think
the place to fix it may be in io.c (resolve_tag)
@@
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37497
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-09-14 19:01
---
Subject: Bug 35840
Author: jvdelisle
Date: Sun Sep 14 19:00:26 2008
New Revision: 140366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140366
Log:
2008-09-14 Jerry DeLisle [EMAIL PROTECTED]
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-14 19:09 ---
On a Core2 2.1Ghz, the original code gives
[ibook-dhum] f90/bug% time gfc pr34554.f90
193.792u 0.273s 3:14.46 99.7% 0+0k 0+27io 0pf+0w
[ibook-dhum] f90/bug% time a.out
152 135210384
0.000u 0.001s
--- Comment #17 from dje at gcc dot gnu dot org 2008-09-14 19:52 ---
Because the problem is due to garbage collection, it is non-deterministic,
depending on what data GCC generates. I was able to reproduce the problem in a
recent development version of GCC, prior to Honza's patch, but
Looking at my testsuite runs on i386-unknown-freebsd6.3 I noticed the
following testsuite failure.
FAIL: 23_containers/deque/init-list.cc (test for excess errors)
Excess errors:
/var/tmp//ccHEu2Vp.s:5429: Error: junk `(,%eax,4)' after expression
/var/tmp//ccHEu2Vp.s:5429: Error: suffix or
--- Comment #1 from gerald at pfeifer dot com 2008-09-14 20:47 ---
Created an attachment (id=16319)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16319action=view)
init-list.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
--- Comment #2 from gerald at pfeifer dot com 2008-09-14 20:47 ---
Created an attachment (id=16320)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16320action=view)
init-list.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
Since revision 139590 (including) GCC fails to build successfully. Revision
139589 can be built successfully with the same configuration.
Configuration:
../trunk/configure --prefix=/usr/local/avr --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
Output when
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-09-14 21:29
---
Patch committed in Comment #7 only eliminates the ICE. Reduction of the
initialization expression remains.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
--- Comment #18 from jorn dot amundsen at ntnu dot no 2008-09-14 22:01
---
(In reply to comment #17)
I tried with a patched 4.3.2, and it does unfortunately *not* fix the problem.
The compiler line (as read from -###) results in:
$
When attempting a bootstrap including libstdc++-v3, the following error will be
encountered.
libtool: compile: /mingw/src/gccf/./gcc/xgcc -shared-libgcc
-B/mingw/src/gccf/./gcc -nostdinc++
-L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src
-L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src/.libs
--- Comment #1 from eric dot weddington at atmel dot com 2008-09-15 03:18
---
Anatoly Sokolov committed a patch as revision 140360 that may (or may not) fix
this problem. See his post on the patches list:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01054.html
Please try a more recent
--- Comment #19 from dje at gcc dot gnu dot org 2008-09-14 22:42 ---
First, you reported seven ICEs. You attached files for
makeChemkinReactions.ii. That file failed before Honza's patch and does not
appear to fail after his patch. I cannot reproduce the failure using my
version of
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-15 01:15 ---
Hmm, I posted a patch which fixes some of this but we still don't get rid of
the extra zero extend because of the way variables are promoted. Boo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-14 22:24 ---
leal$_48(,%eax,4), %eax
...
subl$$_48, %eax
Hmm
Looks like someone forgot a $ encoding in some cases.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #20 from jorn dot amundsen at ntnu dot no 2008-09-15 04:42
---
(In reply to comment #19)
I am sorry, You are right. I thought it fixed everything, though. I will check
4.3.2 + the cp/pt.c patch against every of the 7 original ICE's and give an
updated status on everyone in
--
aaronavay62 at aaronwl dot com changed:
What|Removed |Added
CC||dannysmith at users dot
|
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-15
02:57 ---
I guess the solution is to make libstdc++ use _vsnwprintf instead of vswprintf
on *-mingw32.
I think that is the most expedient solution. Would an inline redirection of
vswprintf to
--- Comment #11 from lthode at mail dot unomaha dot edu 2008-09-15 01:03
---
(In reply to comment #9)
Thanks for the explanation, for the branch I would recommend an extra DCE
pass right before pass_del_ssa. On the trunk we need to make sure to run
this at -O0 as well. Note that
Anyone who doesn't hate homework is
cr'r'r'r'r'r'r'r'r'r'raz'z'z'zz'z'z'z'z'z'z'z'zy!
Nick Cocchiarella
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
Skype: coolcocch
I would encourage you to check out the google group Blind Teen
Talk, a group specifically oriented at
65 matches
Mail list logo
