--- Comment #3 from hjl at gcc dot gnu dot org 2008-10-26 06:54 ---
Subject: Bug 37884
Author: hjl
Date: Sun Oct 26 06:53:25 2008
New Revision: 141371
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141371
Log:
2008-10-25 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #6 from hjl at gcc dot gnu dot org 2008-10-26 07:16 ---
Subject: Bug 37813
Author: hjl
Date: Sun Oct 26 07:14:49 2008
New Revision: 141372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141372
Log:
2008-10-25 Vladimir Makarov [EMAIL PROTECTED]
PR
A bitfield, less than 64 bits, does not zero out when a 1 is shifted left
passed the left most bit. The following test will return 65 instead of 57.
command line:
gcc -Wall -O2 gcc-bitfield-bug.c
gcc-bitfield-bug.c:
#include stdio.h
//64 bit bitfield
struct aa {
unsigned long long f:( 56 )
--- Comment #1 from ata at earthdetails dot com 2008-10-26 07:22 ---
Created an attachment (id=16550)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16550action=view)
test case
The test produces 57 without the optimizer and 65 with the optimizer (-O2)
--
--- Comment #4 from kkojima at gcc dot gnu dot org 2008-10-26 08:26 ---
sh_reorg might insert a new mova in SH_FIXUP_PCLOAD phase.
When untangle_mova looks this mova insn, it may not be associated
with the insn address yet but the current code takes its undefined
address. It seems that
--- Comment #3 from nizze86 at hotmail dot com 2008-10-26 11:25 ---
Created an attachment (id=16551)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16551action=view)
Reduced testcase
A reduced testcase derived from the preprocessed sources.
--
--- Comment #4 from nizze86 at hotmail dot com 2008-10-26 11:28 ---
(In reply to comment #3)
Created an attachment (id=16551)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16551action=view) [edit]
Reduced testcase
A reduced testcase derived from the preprocessed sources.
I noticed that a recent change in gcc with -std=c++0x causes the compilation of
one of my programs to fail. I was using boost regular expressions.
stl_pair:166
#include iostream
#include boost/regex.hpp
int main()
{
boost::regex expression(^[:space:]*#);
char buf[1024];
When compiling the attached code, I get an ICE:
$ /usr/lib/gcc-snapshot/bin/g++ -v -Q -save-temps -c ice.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
20080404-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--- Comment #1 from gcc at keithr dot com 2008-10-26 17:36 ---
Created an attachment (id=16552)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16552action=view)
preprocessed source file that triggers the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37920
__builtin_constant_p seems to be giving a false positive as shown by the
testcase that I'll attach to this bug.
This is causing a warning in the Linux kernel build
--
Summary: __builtin_constant_p seems to be giving false positives
Product: gcc
Version: 4.3.0
--- Comment #1 from arjan at linux dot intel dot com 2008-10-26 18:17
---
Created an attachment (id=16553)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16553action=view)
test case for bug 37921
gcc -c -Wall -Os -fno-strict-aliasing -o fadt.o fadt.c
leads to:
fadt.c: In
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-26 18:24
---
Doug, can you advice about this issue? Otherwise, to be safe, I have to revert
for 4.4.0 your patch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Platform:
Fedora release 8 (Werewolf)
Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008
x86_64 x86_64 x86_64 GNU/Linux
% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure
--- Comment #10 from manu at gcc dot gnu dot org 2008-10-26 22:01 ---
It seems that the problem is cp_parser_template_id fails to parse Yint as a
template-id because when it does a lookup it finds that Y is just a
non-template class and concludes that Yint cannot be a template-id. This
--- Comment #2 from hjl dot tools at gmail dot com 2008-10-26 22:06 ---
*** This bug has been marked as a duplicate of 36902 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #24 from hjl dot tools at gmail dot com 2008-10-26 22:06
---
*** Bug 37921 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2008-10-26 22:12 ---
There is no warning in GCC 4.4, not even with pedantic. Should we really try to
warn about this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16804
--- Comment #3 from manu at gcc dot gnu dot org 2008-10-26 22:24 ---
H.J. Lu
Why do you think this is a duplicate? I will keep it open and see if the patch
that fixes PR 36902, also fixes this.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-26 22:40 ---
BTW, this is confirmed in GCC 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-10-27 00:17 ---
(In reply to comment #3)
H.J. Lu
Why do you think this is a duplicate? I will keep it open and see if the patch
that fixes PR 36902, also fixes this.
Because PR 36902 is a reduced testcase from the source
--- Comment #25 from pinskia at gcc dot gnu dot org 2008-10-27 00:17
---
*** Bug 37921 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-27 00:18 ---
With out a testcase, it is hard to tell if it was reported before or not. Also
does -fwrapv allows for the code to work?
what type is rot_mx?
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37920
--- Comment #6 from manu at gcc dot gnu dot org 2008-10-27 00:20 ---
Then the reduction missed something because I have a patch that fixes pr36902
and it doesn't fix this.
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01117.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37921
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-27 00:22 ---
This is correct behavior. C99 inline by itself is what GNU C90 calls extern
inline. That is inline if it can be, otherwise don't emit code for the
function. extern inline for C99 says always emit the function.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-27 00:26 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37920
Building gcc trunk with...
../gcc-4.4-20081026/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-
arch=nocona --with-tune=generic --build=i686-apple-darwin9 --with-gmp=/sw
--with-libiconv-prefix=/sw
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:49 ---
Created an attachment (id=16554)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16554action=view)
Toplevel Makefile from 20081016 build on i686-apple-darwin9
--
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:50 ---
Created an attachment (id=16555)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16555action=view)
libcpp level Makefile from 20081016 build on i686-apple-darwin9
--
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:51 ---
Created an attachment (id=16556)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16556action=view)
Toplevel Makefile from 20081026 build on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:52 ---
Created an attachment (id=16557)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16557action=view)
libcpp level Makefile from 20081026 build on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:56 ---
Created an attachment (id=16558)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16558action=view)
toplevel config.log from 20081016
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:56 ---
Created an attachment (id=16559)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16559action=view)
libcpplevel config.log from 20081016
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:57 ---
Created an attachment (id=16560)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16560action=view)
toplevel config.log from 20081026
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-10-27
00:58 ---
Created an attachment (id=16561)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16561action=view)
libcpplevel config.log from 20081026
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-10-27
01:02 ---
Created an attachment (id=16562)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16562action=view)
toplevel config.log from 20081026
--
howarth at nitro dot med dot uc dot edu changed
--- Comment #20 from danglin at gcc dot gnu dot org 2008-10-27 01:17
---
Subject: Bug 37316
Author: danglin
Date: Mon Oct 27 01:16:13 2008
New Revision: 141380
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141380
Log:
2008-10-26 John David Anglin [EMAIL PROTECTED]
--- Comment #1 from joefoxreal at gmail dot com 2008-10-27 01:26 ---
similar problem for mipsel-linux on 64bit loongson2f:
When I try to build gcc-4.4.0 20081022 on loongson2f machine, an error
occurs on the stage3,
/home/xmj/tools/build-svn-gcc/./prev-gcc/xgcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-27 01:32 ---
Reduced testcase:
templatetypename T T ensure_obj(const T);
template typename T
void func2(T t)
{
typedef __typeof__(ensure_obj(t)) ttt;
struct ttt1
{
ttt1( ttt arg0 ){}
} ( t );
}
main()
{
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-27 01:42 ---
This was fixed by the patch which fixes PR 33887 So only a 4.2 regression.
-fno-tree-loop-im is a work around for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-10-27 01:49 ---
This requires us to record that the macros came from system headers and so did
the expansion.
Also -Wunreachable-code is useless for most cases in general because of
inlining and such.
--
pinskia at gcc dot gnu
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-27 01:57 ---
Confirmed.
1620 if (e-dest != bb-next_bb
1621 e-dest != EXIT_BLOCK_PTR
1622 single_succ_p (e-dest)
1623 single_succ_edge (e-dest)-dest ==
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|CPPFLAGS now unset for stage|[4.4
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-10-27 02:00 ---
3.3 did not ICE but did give the wrong error message:
t.cc: In instantiation of `func2(T) [with T = double]::ttt1':
t.cc:10: instantiated from `void func2(T) [with T = double]'
t.cc:15: instantiated from here
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from rwgk at yahoo dot com 2008-10-27 02:18 ---
(In reply to comment #1)
With out a testcase, it is hard to tell if it was reported before or not.
Also
does -fwrapv allows for the code to work?
Yes!
(FWIW: -ftrapv doesn't help.)
what type is rot_mx?
A
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-27 02:27 ---
Since decltype has been declared as the replacement for typeof in C++. I am
going to close this meta-bug as won't fix and also all the bugs which this bug
referecnes to are fixed.
--
pinskia at gcc dot gnu dot
--- Comment #10 from drow at gcc dot gnu dot org 2008-10-27 02:45 ---
Do you have:
2008-10-24 Daniel Jacobowitz [EMAIL PROTECTED]
* Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo.
* Makefile.in: Regenerated.
What was previously setting CPPFLAGS? I don't see
[EMAIL PROTECTED]:~/volatile/tmp51$ current-gcc -O small.c
small.c: In function func_142:
small.c:15: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:219
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for
both libcpp/configure of 20081016 and
20081026 are
properly setting CPPFLAGS in the libcpp/Makefile, after your changes setting of
CPPFLAGS now
also occurs in the toplevel Makefile and that is being used instead of the
setting of CPPFLAGS in
libcpp/Makefile. Notice even though the build fails
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-10-27
03:45 ---
I notice that both config.log from the libcpp subdirectory before and after
your change have...
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=
which is followed by the occurance of...
52 matches
Mail list logo
