--- Comment #17 from pault at gcc dot gnu dot org 2009-05-10 07:23 ---
Subject: Bug 38863
Author: pault
Date: Sun May 10 07:23:30 2009
New Revision: 147329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147329
Log:
2009-05-10 Paul Thomas
PR fortran/38863
* tr
--- Comment #18 from pault at gcc dot gnu dot org 2009-05-10 08:56 ---
Problem in comment #1 is fixed on trunk.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-10 09:14
---
Well, that revision only enabled vectorization support for more things...
(which is probably what makes this a regression in the first place).
--
rguenth at gcc dot gnu dot org changed:
What|Rem
--- Comment #13 from irar at il dot ibm dot com 2009-05-10 09:20 ---
(In reply to comment #12)
> Well, that revision only enabled vectorization support for more things...
> (which is probably what makes this a regression in the first place).
Right, I think it is something in the strided
--- Comment #5 from laurent at guerby dot net 2009-05-10 09:28 ---
For the record at rev 147290 even with c++ disabled the bootstrap failed on
libmudflap:
libtool: compile: /home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/
-B/n/50/guerby/install-trunk-147290/armv5tel-unknown-l
Please consider the following code:
module m
implicit none
private
public :: public_t
public :: public_sub
!public :: private_t (*)
type :: private_t
integer :: i
end type
type :: public_t
type(private_t), pointer :: public_comp_with_private_type !(#1)
procedur
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-10 09:40
---
System type? More generally, please provide all the informations detailed in:
http://gcc.gnu.org/bugs.html
Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-10 09:42 ---
Testcase that fails at -O1 (the key is that reverse needs to be inlined):
extern void abort (void);
static void __attribute__((always_inline))
reverse(int *first, int *last)
{
if (first == last--)
return;
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-10 09:52 ---
It is number of iteration analysis that gets it wrong (I suppose it might get
confused by the two exits of the loop?).
Disabling loop header copying makes the code easier to analyze.
--
rguenth at gcc dot gnu dot
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-05-10 10:00
---
Another possible solution that was mentioned is to delay stack slot allocation
until after scheduling (or possibly later code motion optimizations). Before
that stack slots could be represented by their own pseudo
--- Comment #6 from sascha-web-gcc dot gnu dot org at silbe dot org
2009-05-10 10:07 ---
> /* X86_TUNE_USE_FFREEP */
> m_AMD_MULTIPLE,
Without having dug into the source, I'd guess that this is the exact location
of the bug.
> #define m_AMD_MULTIPLE (m_K8 | m_ATHLON | m_AMDFAM10)
I
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-10 10:14
---
It's the default contructor of std::locale.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-10 10:16 ---
Subject: Bug 40081
Author: rguenth
Date: Sun May 10 10:16:01 2009
New Revision: 147330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147330
Log:
2009-05-10 Richard Guenther
PR tree-optimization/
--- Comment #7 from pault at gcc dot gnu dot org 2009-05-10 10:21 ---
Subject: Bug 40018
Author: pault
Date: Sun May 10 10:21:08 2009
New Revision: 147331
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147331
Log:
2009-05-10 Paul Thomas
PR fortran/40018
* tra
--- Comment #8 from pault at gcc dot gnu dot org 2009-05-10 10:22 ---
Subject: Bug 40018
Author: pault
Date: Sun May 10 10:22:37 2009
New Revision: 147332
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147332
Log:
2009-05-10 Paul Thomas
PR fortran/40018
* tra
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-05-10 10:29 ---
New SRA handles this fine by not scalarizing anything that has volatile fields
in it. There is already a fortran testcase with a union with a volatile field
that made me aware of this.
--
http://gcc.gnu.org/bugz
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-10 10:42
---
David, are you aware of implementations not affected by this problem while
providing thread-safe locale::locale() and locale::global, thus much smarter in
the way ios_base deals with locale or you have a feelin
--- Comment #13 from pault at gcc dot gnu dot org 2009-05-10 10:44 ---
Subject: Bug 39879
Author: pault
Date: Sun May 10 10:44:22 2009
New Revision: 147336
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147336
Log:
2009-05-10 Paul Thomas
PR fortran/39879
* tr
--- Comment #14 from irar at il dot ibm dot com 2009-05-10 11:00 ---
I am testing:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 147329)
+++ tree-vect-data-refs.c (working copy)
@@ -1424,7
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-10
11:17 ---
(In reply to comment #4)
> Hello Dave,
Hi Danny!
> Rather than use DLL linkage (and so force client to resort to auto-import
> magic)
> why not just always emit the RTTI with one-only comdat linkage.
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-05-10 11:36 ---
Subject: Bug 40084
Author: hubicka
Date: Sun May 10 11:36:11 2009
New Revision: 147337
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147337
Log:
PR middle-end/40084
* cgraph.c (cgraph_update
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-10 11:52 ---
Hm. I wonder how the "global" locale is supposed to interact with multiple
threads anyway (in the face of C++ not knowing about threads). Would it be
a conforming implementation to put the global locale into thread
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-10 12:12 ---
Btw, from a quick look the global mutex could be easily replaced with
atomic updates of the reference counts (it seems they already are
atomic) and atomic exchanges of the locale pointer.
Atomically fetching the cur
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-10 12:14 ---
Thus, I was meaning to say that
Index: src/locale_init.cc
===
--- src/locale_init.cc (revision 147329)
+++ src/locale_init.cc (working copy)
@@ -208,
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-10 12:21 ---
I should scroll down - ignore my comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
--- Comment #8 from paolo dot carlini at oracle dot com 2009-05-10 12:34
---
:) In any case, before attempting anything here, I recommend also re-analyzing
libstdc++/12658.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #15 from steven at gcc dot gnu dot org 2009-05-10 13:51 ---
The late stack slot allocation idea will just cause other problems, like
missing CSE of addresses. GCC should just get the conflicts right somehow...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--- Comment #16 from rguenther at suse dot de 2009-05-10 14:14 ---
Subject: Re: [4.3/4.4/4.5 Regression] tree-ssa-sink
breaks stack layout
On Sun, 10 May 2009, steven at gcc dot gnu dot org wrote:
> --- Comment #15 from steven at gcc dot gnu dot org 2009-05-10 13:51
> ---
>
--- Comment #17 from steven at gcc dot gnu dot org 2009-05-10 14:22 ---
How will dropping the MEM_EXPRs solve the wrong coalescing in cfgexpand?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--- Comment #7 from ubizjak at gmail dot com 2009-05-10 14:28 ---
(In reply to comment #6)
> > /* X86_TUNE_USE_FFREEP */
> > m_AMD_MULTIPLE,
> Without having dug into the source, I'd guess that this is the exact location
> of the bug.
>
> > #define m_AMD_MULTIPLE (m_K8 | m_ATHLON | m
--- Comment #18 from rguenther at suse dot de 2009-05-10 14:32 ---
Subject: Re: [4.3/4.4/4.5 Regression] tree-ssa-sink
breaks stack layout
On Sun, 10 May 2009, steven at gcc dot gnu dot org wrote:
> --- Comment #17 from steven at gcc dot gnu dot org 2009-05-10 14:22
> ---
>
Revision 147330
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00304.html
caused:
FAIL: 26_numerics/slice_array/array_assignment.cc (test for excess errors)
FAIL: 26_numerics/slice_array/requirements/explicit_instantiation.cc (test for
excess errors)
FAIL: 26_numerics/valarray/27867.cc (test for exces
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/t
hunk3.C -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/inc
lude/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-h
--- Comment #19 from pault at gcc dot gnu dot org 2009-05-10 15:35 ---
Subject: Bug 38863
Author: pault
Date: Sun May 10 15:34:55 2009
New Revision: 147345
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147345
Log:
2009-05-10 Paul Thomas
PR fortran/38863
* tr
--- Comment #3 from vvv at ru dot ru 2009-05-10 16:09 ---
> Not really, the move insn is moved to the beginning of the function:
> 0060 :
> 60: 89 f8 mov%edi,%eax
> 62: 83 ff 08cmp$0x8,%edi
> 65: ba 00 00 00 00 mo
--- Comment #14 from pault at gcc dot gnu dot org 2009-05-10 16:09 ---
Subject: Bug 39879
Author: pault
Date: Sun May 10 16:09:02 2009
New Revision: 147346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147346
Log:
2009-05-10 Paul Thomas
PR fortran/39879
* tr
--- Comment #15 from pault at gcc dot gnu dot org 2009-05-10 16:09 ---
Fixed on 4.3, 4.4 and 4.5 - thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from hjl dot tools at gmail dot com 2009-05-10 16:11
---
(In reply to comment #14)
> I am testing:
>
> Index: tree-vect-data-refs.c
> ===
> --- tree-vect-data-refs.c (revision 147329)
> +++ tree-vect-
--- Comment #9 from pault at gcc dot gnu dot org 2009-05-10 16:14 ---
Subject: Bug 40018
Author: pault
Date: Sun May 10 16:14:37 2009
New Revision: 147347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147347
Log:
2009-05-10 Paul Thomas
PR fortran/40018
* tra
--- Comment #10 from pault at gcc dot gnu dot org 2009-05-10 16:15 ---
Fixed on trunk and 4.4
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
When compile trysto expand:
: seq
< integral_c
< Integral
, Vals
>...
the error diagnostic prints integral_c instead of
integral_c. The integral_constant template
is derived from integral_c and does have T and val args:
struct integral_constant:public mpl::integral_c < T, val >
--- Comment #3 from cppljevans at suddenlink dot net 2009-05-10 16:24
---
Created an attachment (id=17846)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17846&action=view)
system type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
--- Comment #2 from cppljevans at suddenlink dot net 2009-05-10 16:22
---
Created an attachment (id=17845)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17845&action=view)
compilation output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
--- Comment #1 from cppljevans at suddenlink dot net 2009-05-10 16:22
---
Created an attachment (id=17844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17844&action=view)
The .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
Because memory controller prefetch memory blocks, execution time of functions
calls sequence depend on order this functions in memory. For example:
4 calls:
call func1
call func2
call func3
call func4
faster in case of direct functions order in memmory:
.p2align 4
func1:
ret
.p2align 4
func
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-10 16:41 ---
Subject: Bug 40081
Author: rguenth
Date: Sun May 10 16:40:55 2009
New Revision: 147349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147349
Log:
2009-05-10 Richard Guenther
PR tree-optimization/
--- Comment #1 from vvv at ru dot ru 2009-05-10 16:43 ---
Created an attachment (id=17847)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17847&action=view)
Example direct/inverse calls
Simple example. RDTSC ticks for direct and inverse sequence of calls.
--
http://gcc.gnu.org
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-10 16:49 ---
This should have been done already with cgraph order.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from hjl dot tools at gmail dot com 2009-05-10 16:55 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-05-10 17:06 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #8 from sascha-web-gcc dot gnu dot org at silbe dot org
2009-05-10 17:12 ---
> Can you send the output of "gcc -march=native -v"? It looks that the driver
> doesn't detect correctly the type of your CPU.
=== Begin ===
Using built-in specs.
Target: i486-linux-gnu
Configured
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-10 17:17 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from bonzini at gnu dot org 2009-05-10 17:22 ---
Well, if only -O1 fails now, it is almost definitely my patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-10 17:26 ---
I also see these on x86_64 and i?86. My bet is on honza, as usual ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from ubizjak at gmail dot com 2009-05-10 17:51 ---
(In reply to comment #8)
> > Can you send the output of "gcc -march=native -v"? It looks that the driver
> > doesn't detect correctly the type of your CPU.
Uh, I mean "gcc -march=native -### hello.c"
It should return so
--- Comment #10 from sascha-web-gcc dot gnu dot org at silbe dot org
2009-05-10 18:05 ---
Here you go:
o...@debxo:~$ gcc -march=native -### hello.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-3'
--with-bugurl=file://
--- Comment #3 from vvv at ru dot ru 2009-05-10 18:08 ---
(In reply to comment #2)
> This should have been done already with cgraph order.
Unfortunately, I can see inverse order only in separate source file. Inverse
but not optimized.
Example:
// file order1.c
#include
main(int argc,
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-10 18:10 ---
Well you need whole program to get the behavior which you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40093
--- Comment #6 from matz at gcc dot gnu dot org 2009-05-10 18:17 ---
I haven't yet committed the patch that Ramana tested. Have you applied it
manually? Otherwise the breakage is expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
--- Comment #5 from vvv at ru dot ru 2009-05-10 18:20 ---
(In reply to comment #4)
> Well you need whole program to get the behavior which you want.
Yes. Of course, it's no problem for small single-programmer project, but it's
problem for big projects like Linux Kernel.
--
http://g
--- Comment #7 from laurent at guerby dot net 2009-05-10 18:23 ---
I confirm I didn't apply your patch on the build that failed libmudflap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
--- Comment #24 from danglin at gcc dot gnu dot org 2009-05-10 18:40
---
I see this on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from matz at gcc dot gnu dot org 2009-05-10 18:40 ---
Subject: Bug 40031
Author: matz
Date: Sun May 10 18:40:16 2009
New Revision: 147350
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147350
Log:
PR target/40031
* config/arm/arm.c (require_pic_reg
--- Comment #9 from matz at gcc dot gnu dot org 2009-05-10 18:41 ---
Now I have, hence fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Stat
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64
Revision 147342/147343 caused:
FAIL: gcc.dg/Wunreachable-2.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/flatten-2.c scan-assembler-not indirect[12][: \t\n]
on Linux/ia32 and Linux/x86-64.
--
Summary: [4.5 Regression] Revision 147342/147343 caused extra
failur
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-10 19:26 ---
(In reply to comment #2)
> Well, if only -O1 fails now, it is almost definitely my patch.
It definitely is, there are no other authors in that revision range! :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-05-10 19:51 ---
This is latent problem in -Wunreachable.
We now unroll the loop:
void bar (void)
{
int i;
for (i = 0; i < 2; i++)
if (! foo (a[i]))
return;
baz (); /* { dg-bogus "will never be executed" } */
--- Comment #15 from gustcr at yahoo dot com dot ar 2009-05-10 19:52
---
I tried the first suggested option, on building gcc-4.4.0. It seems to work but
now it fails later with the message:
/usr/include/stdlib.h:305: multiple definition of `atof'
.libs/backtrace.o:/usr/include/stdlib.h
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-10 20:17
---
This is seen only on hpux and frankly I have no idea how the recent changes to
throw_allocator (which was completely broken before) could have caused it: I
would suggest taking the testcase out of the testsuite
--- Comment #16 from dominiq at lps dot ens dot fr 2009-05-10 20:27 ---
You may want to have a look at pr29867.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-10 20:39 ---
-Wunreachable is completely bogus anyway, I suggest to XFAIL the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
--- Comment #11 from ubizjak at gmail dot com 2009-05-10 20:55 ---
(In reply to comment #10)
> COLLECT_GCC_OPTIONS=
> "/usr/lib/gcc/i486-linux-gnu/4.3.3/cc1" "-quiet" "hello.c" "-march=athlon"
> "--param" "l1-cache-size=64" "--param" "l1-cache-line-size=32" "-mtune=athlon"
> "-quiet" "
--- Comment #12 from sascha-web-gcc dot gnu dot org at silbe dot org
2009-05-10 21:21 ---
"Geode by NSC" seems to be the "original" Geode series developed by National
Semiconductor. According to Wikipedia [1], AMD bought the Geode "business",
released the original design as "GX series"
--- Comment #13 from ubizjak at gmail dot com 2009-05-10 22:00 ---
Created an attachment (id=17848)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17848&action=view)
Patch
This patch looks at processor name to detect AMD geode CPU. As far as gcc is
concerned, "-march=geode" means A
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-10 22:07 ---
cris-elf too...
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC|
Hi
I'm going to attach a small test case that used to work until my gentoo system
upgraded gcc to 4.3.2. It is not a vanilla build, but I'm not able to easy test
this on a vanilla system.
For my failing system, the output from the test case is:
0x81 0x82 0x03 => 0x4103
0x81 0x82 0x03 => 0x00
--- Comment #1 from stian at nixia dot no 2009-05-10 22:21 ---
Created an attachment (id=17849)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17849&action=view)
test.c
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40096
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-10 22:38 ---
This code is undefined because are there are two stores to test2 without a
sequence point.
test2+=readvlnum(&test2);
Can be evaluated like:
tmp1 = test2;
tmp2 = readvlnum(&test2);
test2 = tmp1 + tmp2;
Or:
tmp
The following code results in a segmentation fault at Line 7.
1:#include
2:int main(){
3: const char *tmp = NULL;
4: printf("%s \n",NULL);
5: printf("%s\n",NULL);
6: printf("%s \n",tmp);
7: printf("%s\n",tmp);
8: return 1;
9:}
I've traced the bug to the code optimiz
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-11 01:15 ---
Actually this code is undefined. Using %s with a NULL pointer is undefined so
GCC's behavior is correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from Andrey dot Martchovsky at gmail dot com 2009-05-11
01:26 ---
(In reply to comment #1)
> Actually this code is undefined. Using %s with a NULL pointer is undefined so
> GCC's behavior is correct.
>
You are wrong, the GCC behavior is incorrect.
Please compile code a
--
Summary: 64bit constants
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Andrey dot Martchovsky at
The following code produces
and...@tiny:~/Documents/Thesis/TIA/pll$ gcc tst.c
tst.c:2: warning: integer constant is too large for âlongâ type
and...@tiny:~/Documents/Thesis/TIA/pll$ g++ tst.c
tst.c:2: error: integer constant is too large for âlongâ type
1:#include
2:long long int tst
--- Comment #1 from Andrey dot Martchovsky at gmail dot com 2009-05-11
02:07 ---
*** This bug has been marked as a duplicate of 40099 ***
--
Andrey dot Martchovsky at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from Andrey dot Martchovsky at gmail dot com 2009-05-11
02:07 ---
*** Bug 40098 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40099
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-11 04:38 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Actually this code is undefined. Using %s with a NULL pointer is undefined
> > so
> > GCC's behavior is correct.
> >
>
> You are wrong, the GCC behavior is
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-11 06:08 ---
Why is that a problem? C and C++ are different languages. Compiling with g++
means you are compiling the C code as C++ (see documentation).
--
jakub at gcc dot gnu dot org changed:
What|Removed
89 matches
Mail list logo
