I am familiar with C++, Do not recommend C++ to me.
gcc initial the first member of union now, This is not the C standard also.
I just want gcc initial the last member of union with some switch.
2010/6/11 Magnus Fromreide ma...@lysator.liu.se:
On Fri, 2010-06-11 at 08:44 +0800, yuanbin wrote:
On Thu, Jun 10, 2010 at 10:26 PM, Andi Kleen a...@firstfloor.org wrote:
Hi Honza,
Here's an idea to make it easier to manually annotate
large C code bases for hot/cold functions where
it's too difficult to use profile feedback.
It's fairly common here to call function through
function
Richard Guenther richard.guent...@gmail.com writes:
Iff the inheritence is restricted to initializers like in the above example
it should be straight-forward to implement in the frontends.
Great.
For best results would need some inheritance to callees too, if the
callees are not called by
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther
On 06/11/2010 10:15 AM, yuanbin wrote:
gcc initial the first member of union now, This is not the C standard also.
I just want gcc initial the last member of union with some switch.
Why do you want the last one? Is there a compiler that does that (e.g.
MSVC++)? If yes, it can be toggled by
On 11 June 2010 14:40, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
On Fri, Jun 11, 2010 at 2:57 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:40, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther
i have pushed the patch on mob
Coo: initial last member of union
Please change my name of patch: U-YUAN\Administrator - yuanbin
2010/6/11 grischka gris...@gmx.de:
Too all:
Please push patches on our mob branch:
http://repo.or.cz/w/tinycc.git
People who don't like/know git: at least base
On 11/06/2010 13:59, Richard Guenther wrote:
Well, we can't. We specifically support mixed LTO/non LTO objects
(think of shared libraries for example). With the linker-plugin and gold
we can do better, but with just GNU ld and collect2 we can't.
Well then shouldn't we warn if
On Fri, Jun 11, 2010 at 3:21 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
On 11/06/2010 13:59, Richard Guenther wrote:
Well, we can't. We specifically support mixed LTO/non LTO objects
(think of shared libraries for example). With the linker-plugin and gold
we can do better, but with
Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly
Application. Gold support for our target is still far away. I found
-fwhole-program
is very important for our size optimization.
Bingfeng
-Original Message-
From: Dave Korn
On Fri, Jun 11, 2010 at 3:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly
Application. Gold support for our target is still far away. I found
-fwhole-program
is very important for our size optimization.
True.
On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com wrote:
Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly
Application. Gold support for our target is still far away. I found
-fwhole-program
is very important for our size optimization.
But if I understand
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: 11 June 2010 14:08
To: Bingfeng Mei
Cc: Dave Korn; Manuel López-Ibáñez; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 3:04 PM, Bingfeng Mei
-Original Message-
From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
Sent: 11 June 2010 14:14
To: Bingfeng Mei
Cc: Dave Korn; Richard Guenther; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Issue with LTO/-fwhole-program
On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the other object files.
It is really up to user to understand
On 11 June 2010 15:26, Jan Hubicka hubi...@ucw.cz wrote:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the other
On 11/06/2010 14:26, Jan Hubicka wrote:
Perhaps we can somehow poison the object names that are brought local with
-fwhole-program
so linking explode, but I am not sure there is way to do so.
Could emit warning symbols, but, like the others, I don't see why collect2
can't spot this.
On 11/06/2010 14:26, Jan Hubicka wrote:
Perhaps we can somehow poison the object names that are brought local with
-fwhole-program
so linking explode, but I am not sure there is way to do so.
Could emit warning symbols, but, like the others, I don't see why collect2
can't spot
Thanks for the reply. I scrolled a lot through the i386 md and c files. I
notice that the i386 architecture has dedicated
instructions for comparing values and ALU instructions only specify
(clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify
the way ALU instructions affect
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 11 June 2010 15:26, Jan Hubicka hubi...@ucw.cz wrote:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com wrote:
Well, mixed LTO/non-LTO is quite useful. For example, we have mixed
C/assembly
Application. Gold support for our target is still far away. I found
-fwhole-program
is very
Radu Hobincu radu.hobi...@arh.pub.ro writes:
Thanks for the reply. I scrolled a lot through the i386 md and c files. I
notice that the i386 architecture has dedicated
instructions for comparing values and ALU instructions only specify
(clobber (reg:CC FLAGS_REG)). What I do not understand is
On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
On the other hand, I'm not going to argue that it's a lot of work.
Missing not !
When you say put assertions in the assembler output I understood it
to mean in the assembly source code output by the compiler, not the
output
On 06/10/10 14:44, Bernd Schmidt wrote:
On 06/10/2010 10:37 PM, Jeff Law wrote:
Compile the attached with -O2 on x86-unknown-linux-gnu and review the
.ira dump for main()
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Building IRA IR
* Jan Hubicka wrote on Fri, Jun 11, 2010 at 03:26:12PM CEST:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the
On 06/11/2010 06:32 PM, Jeff Law wrote:
But shouldn't having an invariant form just decrease the priority
for pseudo 59 to get a hard register? The NO_REGS preferencing will
totally disable register allocation for pseudo 59.
And that's intended, because from the costs we've concluded that
Quoting Jan Hubicka hubi...@ucw.cz:
Perhaps we can somehow poison the object names that are brought
local with -fwhole-program
so linking explode, but I am not sure there is way to do so.
The linker will generally emit a diagnostic when the size or alignment
of a symbol increases, or the
On 06/11/10 10:48, Bernd Schmidt wrote:
On 06/11/2010 06:32 PM, Jeff Law wrote:
But shouldn't having an invariant form just decrease the priority
for pseudo 59 to get a hard register? The NO_REGS preferencing will
totally disable register allocation for pseudo 59.
And that's
Hi,
I am trying to dump the final-most gimple (in ssa) file. My understanding is
that lto encodes GIMPLE IR in the bytestream of the object files and
accordingly I invoke PLUGIN_PASS_MANAGER_SETUP to embed my faux dummy pass
after 'pass_ipa_lto_finish_out'. Is ssa information available at the
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific combination. I think making this mistake would be quite easy
but hard to debug.
It's not only correct, it's essential. Whole Program doesn't mean
that
On 06/11/2010 03:26 PM, Jan Hubicka wrote:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the other object files.
It
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
d...@codesourcery.com wrote:
On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
[snip]
Does this qualify as a form of what you are suggesting? Because this
is exactly what is being proposed:
.balign 8 # start
On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
d...@codesourcery.com wrote:
On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
[snip]
Does this qualify as a form of what you are suggesting?
On Fri, Jun 11, 2010 at 02:09:33PM -0500, Quentin Neill wrote:
Currently GCC doesn't compute the current encoding offset (doesn't
know mnemonic/opcode lengths),
That's not true, gcc for i?86/x86_64 actually calculates the length and for
most of the commonly used insns correctly, I've spent
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific combination. I think making this mistake would be quite easy
but hard to debug.
It's
On 11 June 2010 21:41, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific combination. I
On Fri, Jun 11, 2010 at 12:50 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 21:41, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost
Manuel López-Ibáñez lopeziba...@gmail.com writes:
This also means that linking your program with non-LTO+whole-program
code may lead to miscompilations without any warning, which is really
bad. I don't think it is a reasonable limitation and we will get bad
press when programs start breaking
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
[snip]
x86 assembler isn't an optimizing assembler. -mtune only does
instruction selection. What you are proposing sounds like an optimizing
assembler to me. Are we going to support scheduling, macro, ...?
--
H.J.
Just to
On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote:
But if I understand correctly, mixed LTO/non-LTO + whole-program is
almost never correct. So we should really emit a warning for this
specific
All,
When I link with a shared library, for example:
env LD_RUN_PATH=/usr/lib /usr/bin/gcc -shared -fPIC
-L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o
blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib
/usr/lib/libconfig.so
the ld command follows the version, and
Edward Peschko horo...@gmail.com writes:
When I link with a shared library, for example:
env LD_RUN_PATH=/usr/lib /usr/bin/gcc -shared -fPIC
-L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o
blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib
/usr/lib/libconfig.so
--- Comment #1 from Denis dot Excoffier at airbus dot com 2010-06-11 08:05
---
The same applies to mpfr-3.0.0 (now official). The MPFR people have however
added the following note in ./INSTALL:
As gmp-impl.h and longlong.h are only in the GMP source directory,
you first need to copy
--- Comment #5 from iains at gcc dot gnu dot org 2010-06-11 08:32 ---
closing as fixed after back-porting to the 4.5 release branch at r160482
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from iains at gcc dot gnu dot org 2010-06-11 08:36 ---
is this now fixed?
in 4.5 after r160526,
and trunk after r160457
which should have made the detection of emulated TLS more reliable.
--
iains at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 08:37 ---
closing as fixed by r160457 (trunk) and r160526 (4.5 release branch)
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #77 from iains at gcc dot gnu dot org 2010-06-11 08:38 ---
no new issues having been reported by the regression testers, closing this as
fixed.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-06-11 08:43
---
I remember discussing that a long while back, and I don't think people had
strong opinions. WONTFIX seems good.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from iains at gcc dot gnu dot org 2010-06-11 08:57 ---
closing as fixed after back-ports to the current release branch (4.5) for
various ObjC fixes including the ones listed here:
r160482, r160541, r160546
--
iains at gcc dot gnu dot org changed:
What
The following code:
class C {
};
class D : public C {
};
const D g_d;
fails to compile on trunk (rev. 160489) with the following message:
$ g++ test.cpp
test.cpp:11:9: error: uninitialized const 'g_d' [-fpermissive]
test.cpp:6:11: note: 'const class D' has no
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 09:10 ---
@r160568 (or earlier) this is no longer showing.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-11 09:26 ---
gcc is correct, accepting the code previously was a bug that was fixed recently
You need to provide an initializer for g_d
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-11 10:27 ---
A question: apart from quoting chapter and verse from the standard (8.5
[dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have
been any clearer?
It indicates you can use -fpermissive to relax the
Compiling with g++ -std=c++0x, using gcc-4.5.0 :
struct A {
char x;
};
templatechar C void f() {
char y = 42;
A a = { y+C };
}
int main() {
f1();
}
yields an error: narrowing conversion of â(((int)y) + 8)â from âintâ
to âcharâ inside { }.
If I change
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:47
---
Reduced testcase at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00131.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:48
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from aoliva at gcc dot gnu dot org 2010-06-11 10:49 ---
Steve, lto and whopr seem to have been introduced in a way that broke VTA.
This is not ia64-specific, and it's not what this bug is about. I guess what
you're seeing are other cases of lossage, that we might have
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-11 10:53 ---
(In reply to comment #1)
gcc is correct, accepting the code previously was a bug that was fixed
recently
You need to provide an initializer for g_d
This sort of changes should be documented in the changes.html
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-11 10:57 ---
I wonder what the C++ standard said because we have the same issue in
Wconversion and Joseph rejected my patch arguing that the operation was done in
the larger type, so there was a narrowing conversion. I still
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-06-11 11:01
---
(In reply to comment #2)
A question: apart from quoting chapter and verse from the standard (8.5
[dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have
been any clearer?
It
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-11 11:11 ---
Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions
ComeauTest.c, line 9: error: const variable
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org
|dot org
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-11 11:13 ---
LLVM is still using GCC in their demo, not Clang. So I cannot test their
output.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
--- Comment #2 from gpiez at web dot de 2010-06-11 11:34 ---
Sorry for the unicode mess. The error message is 'error: narrowing conversion
of (((int)y) + 1) from int to char inside { }'.
The same error happens with a non templated function, but if I use two template
parameters, the
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-11 11:37 ---
'y' and 'C' are both promoted to int and 'y' is not a constant, so the
resulting value cannot be proven to fit in a char, so it's a narrowing
conversion.
If you make 'y' a const int then the value y+C is a constant
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-11 11:42 ---
(In reply to comment #2)
Sorry for the unicode mess. The error I believe I should not get an error,
even if the template parameter type is
larger than a char, as long as the template parameter value fits in in
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-06-11 11:45 ---
Not a bug
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ro at gcc dot gnu dot org 2010-06-11 11:46 ---
Subject: Bug 44216
Author: ro
Date: Fri Jun 11 11:45:59 2010
New Revision: 160602
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160602
Log:
Backport from mainline:
2010-05-25 Rainer Orth
--- Comment #11 from ro at gcc dot gnu dot org 2010-06-11 11:49 ---
Subject: Bug 44216
Author: ro
Date: Fri Jun 11 11:49:16 2010
New Revision: 160603
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160603
Log:
config:
* override.m4 (AC_LANG_WERROR): Redefine to
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44498
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44495
--- Comment #5 from gpiez at web dot de 2010-06-11 12:09 ---
So is it provable that for a T op T to be stored in T no narrowing takes
place?
If the answer for T == char is no and for T == int it is yes this is rather
fishy ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 ---
Created an attachment (id=20887)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20887action=view)
Patch that fixes the problem
Here's the patch I'm testing now.
--
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 ---
*** Bug 44247 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 ---
The patch for bug 44181 fixes this one as well.
*** This bug has been marked as a duplicate of 44181 ***
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-11 12:43 ---
(In reply to comment #2)
It could be a dup of PR 44498.
It if does not turn out to be a dup of the bitmap work / PR 44498, we need a
backtrace or valgrind trace (with minimal options, e.g. -O0 if possible).
--
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-11 12:51 ---
(In reply to comment #5)
So is it provable that for a T op T to be stored in T no narrowing takes
place?
Yes, if the values are constants.
If the answer for T == char is no and for T == int it is yes this is
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 ---
*** Bug 43650 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 ---
Unlike PR43656, this one is also fixed by the patch proposed for PR44181.
*** This bug has been marked as a duplicate of 44181 ***
--
aoliva at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-11 13:07 ---
He is referring to a testcase like:
templatetypename T, T C void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
fint,1();
fchar,1();
}
So, we warn for T == char but not for T ==
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-11 13:20 ---
(In reply to comment #7)
He is referring to a testcase like:
templatetypename T, T C void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
fint,1();
fchar,1();
}
--- Comment #22 from jakub at gcc dot gnu dot org 2010-06-11 13:22 ---
Created an attachment (id=20888)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20888action=view)
gcc46-pr44492.patch
Updated patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
Hello,
it seems if there is a bug in the avr 32 gcc compiler.
avr32-gcc: version 4.3.2
toolchain: avr32-gnu-toolchain-2.4.2-setup.exe
avr32studio: avr32studio-ide-installer-2.5.0.35-win32.win32.x86.exe
Both got from www.atmel.com
Device: UC3B0256
Compilerflags: -O2 -g2 -mpart=uc3b0256
When
--- Comment #9 from gpiez at web dot de 2010-06-11 13:27 ---
I understand now after the implicit promotion to int of a non constant value
the result of the narrowing operation can't be guaranteed to fit in the
original type. But I still think it shouldn't give an error, and if the
--- Comment #1 from roland dot cassebohm at dh-partner dot com 2010-06-11
13:27 ---
Created an attachment (id=20889)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20889action=view)
Test program
This file could be compiled alone with
avr32-gcc -v -save-temps -O2 -g3
--- Comment #2 from roland dot cassebohm at dh-partner dot com 2010-06-11
13:29 ---
Created an attachment (id=20890)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20890action=view)
Listfile with resulted assembler
Generated with:
avr32-objdump.exe -S main.o main.lst
--
--- Comment #3 from roland dot cassebohm at dh-partner dot com 2010-06-11
13:31 ---
Created an attachment (id=20891)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20891action=view)
gcc output
Output of avr32-gcc by using:
avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.o
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-11 13:33 ---
(In reply to comment #8)
In both cases, T+T has type int,
We know that, but I don't think most C/C++ programmers know about integer
promotion rules. We just disagree here. But since this is mandated by the
--
roland dot cassebohm at dh-partner dot com changed:
What|Removed |Added
Severity|normal |critical
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:38
---
(In reply to comment #2)
Still true for gcc version 4.6.0 20100509 (experimental) (GCC)
I don't know if it's worth the extra work, but this can be tackled in
gfc_conv_substring() by checking whether start.expr
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
1 - 100 of 176 matches
Mail list logo
