Hi guys,
In next three years I'm going to get the scientific degree in System
programming.
That's why I'm looking for the interesting and actual theme not like a
new bicycle with square rings.
My degree work in university was connected with value range
propagation (VRP) functionality in clang
The avr backend auto-generates a part of the texi documentation by means
of a small C program. The relevant part of t-avr reads:
s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext)
$(RUN_GEN) $ | sed -e 's:\r::g' avr-mmcu.texi
There was a problem report that the executable cannot be
The avr backend auto-generates parts of GCC's texi documentation,
namely the supported -mmcu= options, which are about 200.
To generate the texi a small C program is used to print the texi
to stdout, and that output is then compared against the already
existing doc/avr-mmci.texi
If the output
Georg-Johann Lay wrote:
The avr backend auto-generates parts of GCC's texi documentation,
namely the supported -mmcu= options, which are about 200.
To generate the texi a small C program is used to print the texi
to stdout, and that output is then compared against the already
existing
On 26 May 2012 11:01, Georg-Johann Lay wrote:
Is there a valid compare tool that compares text modulo line-endings?
POSIX diff with the -b option should report the files as equal, I
don't know if that's portable enough to rely on though.
As Jonathan Wakely wrote:
POSIX diff with the -b option should report the files as equal, I
don't know if that's portable enough to rely on though.
I think it is. The Single Unix Specification requires the -b option
(Cause any amount of white space at the end of a line to be treated
as a
On 12-05-26 04:46 , Serg Anohovsky wrote:
It would be nice, if you suggest me good theme or give me the area
where I could find it.
You can find GCC's VRP implementation in the file gcc/tree-vrp.c in the
source repository
http://gcc.gnu.org/viewcvs/trunk/gcc/tree-vrp.c?view=markup
The
Quoting Georg-Johann Lay a...@gjlay.de:
The avr backend auto-generates parts of GCC's texi documentation,
namely the supported -mmcu= options, which are about 200.
I hope that autogenerated documentation is still helpful then.
Sometimes an overabundance of verbose documentation can prevent a
Georg-Johann Lay a...@gjlay.de writes:
The avr backend auto-generates a part of the texi documentation by
means of a small C program. The relevant part of t-avr reads:
s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext)
$(RUN_GEN) $ | sed -e 's:\r::g' avr-mmcu.texi
There was a
Joern Rennecke amyl...@spamcop.net writes:
Some platforms need b for fopen, others reject it.
Hmm, really?
b seems to standard in ISO-C (and widely used in programs aiming for
portability)...
-miles
--
Bore, n. A person who talks when you wish him to listen.
Snapshot gcc-4.7-20120526 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120526/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
Bug #: 53494
Summary: initializer lists in array type
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-26
09:40:37 UTC ---
In any case a good workaround is using matchSynonyms{{ {smile,1} }}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-05-26 10:09:35
UTC ---
Reduced testcase:
--cut here--
typedef long unsigned int size_t;
extern C
{
extern void *memcpy (void *__dest, __const void *__src, size_t __n);
}
extern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53490
--- Comment #7 from Jamie Allsop ja11sop at yahoo dot co.uk 2012-05-26
10:59:46 UTC ---
(In reply to comment #6)
(In reply to comment #4)
It was a vanilla bjam build of boost 1.49, so
no -std=c++11.
Then technically that's not supported,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50294
--- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-05-26
13:26:01 UTC ---
Author: ebotcazou
Date: Sat May 26 13:25:55 2012
New Revision: 187914
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187914
Log:
PR ada/50294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50294
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52528
--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-05-26
13:55:51 UTC ---
Author: ebotcazou
Date: Sat May 26 13:55:46 2012
New Revision: 187915
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187915
Log:
Backport from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52528
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r187906-install
--program-prefix=r187906- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120526
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43013
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.5/4.6/4.7/4.8|[4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39514
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53495
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37945
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||error-recovery,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53461
t-rexky gvvn1200 at gmail dot com changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.6.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-26
15:16:29 UTC ---
And since it's actually invalid should be pretty easy to fix, the ICE is
happening in a gcc_assert where alignment is handled, nothing to do.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52823
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53496
Bug #: 53496
Summary: gcc segfaults when compiling glic
Classification: Unclassified
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53496
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53493
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-26
17:21:38 UTC ---
Can you provide the preprocessed source?
I think this is done on purpose since foo is not used in the source and the
rules for C++ say the const variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53496
--- Comment #2 from Justas justas.poderys at gmail dot com 2012-05-26
17:25:40 UTC ---
Created attachment 27503
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27503
source of param.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53492
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53480
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Component|libstdc++ |c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53496
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53493
--- Comment #2 from jwatte at gmail dot com 2012-05-26 19:22:01 UTC ---
Note that there is not yet any linkage involved -- this is simply a compile
pass. Specifically, the problem here is that I run into a missing symbol error
when linking a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53493
--- Comment #3 from jwatte at gmail dot com 2012-05-26 19:25:50 UTC ---
Created attachment 27504
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27504
The preprocessed source
Generated with:
avr-gcc -Os -mmcu=atmega328p -c foo.cpp -o foo.E -E
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53493
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2012-05-26
19:42:26 UTC ---
Note, btw, that verify_cgraph() doesn't catch this. Honza, you loved checkers
so much a few years ago -- maybe this checker (also yours??) should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53493
jwatte at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53493
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #5 from mako marcus-yass at ihug dot co.nz 2012-05-26 20:31:39
UTC ---
Would someone please explain to me why that compile error is considered
correct? It tells me nothing sensible.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53486
Jiří Paleček jpalecek at web dot de changed:
What|Removed |Added
Attachment #27499|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-26
21:00:21 UTC ---
Who said correct?!?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
--- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2012-05-26
21:13:27 UTC ---
Author: jason
Date: Sat May 26 21:13:23 2012
New Revision: 187916
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187916
Log:
PR c++/53220
gcc/
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53491
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Summary|[4.7/4.8 Regression] ICE in |[4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53491
--- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-05-26 21:20:44 UTC ---
Author: paolo
Date: Sat May 26 21:20:38 2012
New Revision: 187917
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187917
Log:
/cp
2012-05-26
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #7 from mako marcus-yass at ihug dot co.nz 2012-05-26 21:41:57
UTC ---
Uh, Johnathan said 4.6 correctly rejects it:, however 4.6's rejection message
appears every bit as useless as 4.7's, perhaps more so, because it
misattributes the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53439
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53434
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53424
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-26
23:47:56 UTC ---
(gdb) p debug_tree(t)
indirect_ref 0x76e4c500
type integer_type 0x76e6e000 int readonly SI
size integer_cst 0x76d4d080 constant 32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53405
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53343
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-26
23:54:26 UTC ---
--disable-build-poststage1-with-cxx
Is there a reason why you are using this option?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
gcc -v; gcc version 4.2.1 20070831 patched [FreeBSD]
uname -srip; FreeBSD 9.0-RELEASE i386 GENERI
Compiler command; gcc47 minimalErroringCode.cpp -o minimalErroringCode
Test; ./minimalErroringCode
Expected; no output
Result; Assertion failed: ((buffer[0] = 0xFF) buffer[0] == 0xFF),
function main,
On 5/26/12, Jordan Foster jrdnfst...@gmail.com wrote:
gcc -v; gcc version 4.2.1 20070831 patched [FreeBSD]
uname -srip; FreeBSD 9.0-RELEASE i386 GENERI
Compiler command; gcc47 minimalErroringCode.cpp -o minimalErroringCode
Test; ./minimalErroringCode
Expected; no output
Result; Assertion
On Sat, May 26, 2012 at 8:25 PM, Jordan Foster jrdnfst...@gmail.com wrote:
gcc -v; gcc version 4.2.1 20070831 patched [FreeBSD]
uname -srip; FreeBSD 9.0-RELEASE i386 GENERI
Compiler command; gcc47 minimalErroringCode.cpp -o minimalErroringCode
Test; ./minimalErroringCode
Expected; no output
Hi,
There is an off by one error in neon_evpc_vrev which means it
rarely gets triggerred. The problem is that if you are looking at
d-perm [i +j] and you increment i by just diff you end up starting
looking where you looked at the end of the last place where you
checked. Given this I
To have the name of the types of the variant part and the fields therein be
unique instead of mere duplicates of those of the base type, which makes it
easier to debug type merging issues in LTO mode.
Tested on i586-suse-linux, applied on the mainline, 4.7 and 4.6 branches.
2012-05-26 Eric
There is one more goto in the .optimized dump because the latch of a loop is
now preserved.
Tested on i586-suse-linux, applied on the mainline.
2012-05-26 Eric Botcazou ebotca...@adacore.com
* gnat.dg/renaming5.adb: Adjust dg-final directive.
--
Eric Botcazou
Index:
The problem is that the new call to cleanup_cfg in gimple_expand_cfg has
short-circuited the machinery that emits nops to carry goto locus at -O0.
The machinery works in CFGLAYOUT mode, but here we're still in CFGRTL.
The attached patch makes it so that forwarder blocks are not deleted by
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 2cecf45..9d6983b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7131,6 +7131,8 @@ arm_rtx_costs_1 (rtx x, enum rtx_code outer, int*
total, bool speed)
*total = COSTS_N_INSNS (2);
else if
Il 25/05/2012 12:20, Dinar Temirbulatov ha scritto:
+ emit_store_flag_force (c, GT, u0, tmp, mode, 1, 1);
+ emit_store_flag_force (c1, GT, u1, tmp, mode, 1, 1);
+ result = expand_binop (mode, ior_optab, c, c1, cres, 1,
OPTAB_LIB_WIDEN);
+ if (!result)
+ return
Il 26/05/2012 14:35, Paolo Bonzini ha scritto:
/* We have to return
z2 + ((u0 + u1) GET_MODE_BITSIZE (word_mode)).
u0 + u1 are the upper two words of the three-word
intermediate result and they could have up to
2 * GET_MODE_BITSIZE
Hi,
I found the time to return to this issue, where -Wmissing-braces is
often overeager to warn, thus annoying, for example, people using -Wall
together with std::array:
std::arrayint, 3 s = { 1, 2, 3 };
I handle the issue following the letter of the suggestion given by Ian
at the
Hi,
As described in PR53447, many 64bit ALU operations with constant can be
optimized to use corresponding 32bit instructions with immediate operands.
This is the first part of the patches that deals with 64bit add. It directly
extends the patterns adddi3, arm_adddi3 and adddi3_neon to handle
I think I would rather fix stabilize_expr to handle void arguments
properly: basically just stick the whole argument in *initp and return
void_zero_node.
Jason
On Mon, May 21, 2012 at 9:33 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Apr 11, 2012 at 7:35 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
This patch was an experiment to see if we can get the
On 05/26/2012 04:21 PM, Jason Merrill wrote:
I think I would rather fix stabilize_expr to handle void arguments
properly: basically just stick the whole argument in *initp and return
void_zero_node.
Ok. Like this it works, if I understand your suggestion.
Thanks,
Paolo.
On 05/26/2012 11:31 AM, Paolo Carlini wrote:
Ok. Like this it works, if I understand your suggestion.
Yep, that's what I had in mind. But let's put it after the
!TREE_SIDE_EFFECTS case. OK with that change.
Jason
On Sat, 26 May 2012, Jason Merrill wrote:
In C++, C99 a compound literal creates a temporary object, unlike C, where it
creates an automatic or static object. As a result, using an array compound
literal to initialize a pointer variable leads to undefined behavior, as the
array's lifetime
Hello,
I happened to notice these typos but I don't have commit rights.
Thanks to whoever might pick it up.
-- Oliver
2012-05-26 Oliver Kellogg okell...@users.sourceforge.net
* alloc.ads, exp_dbug.adb, gcc-interface/misc.c, lib.ads, lib-xref.adb,
lib-xref.ads, sem_ch10.adb, sem_ch12.adb,
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam tmsri...@google.com wrote:
On May 25, 2012 7:15 PM, H.J. Lu hjl.to...@gmail.com wrote:
On May 25, 2012 6:54 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri,
... and this is the version of the patch which simply takes
-Wmissing-braces out of -Wall in C++. Bootstrapped and tested all
C-family languages x86-64-linux.
Paolo.
///
Index: doc/invoke.texi
===
---
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam tmsri...@google.com wrote:
On May 25, 2012 7:15 PM, H.J. Lu hjl.to...@gmail.com wrote:
On May 25,
On Sat, May 26, 2012 at 4:56 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam tmsri...@google.com
wrote:
On
Hi,
I still had some cleanups for age-old code lying around, and thought to
bring it up to date. The whole dealing of slots for temporary stack space
in function.c was never really updated to the way we're meanwhile
expanding statements. It has facilities that aren't useful anymore. In
the
Hi,
and this is the large cleanup, removing dead code introduced by [1/3] for
real, and removing the 'keep' parameter from assign_temp and friends,
which now is always zero (in the compiler proper and in the backends).
That latter is the largest churn.
If [1/3] is approved this whole patch is
Hi,
and this is a further small cleanup. pop_temp_slots is now the same as
free_temp_slots (modulo the level-- of course), so there's no need in
calling both. (and preserve_temp_slots(NULL) is useless now).
Regstrapped on x86_64-linux together with [1/3] and [2/3], all languages
On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam tmsri...@google.com wrote:
On Sat, May 26, 2012 at 4:56 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, May 25, 2012 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On
On Sat, May 26, 2012 at 7:06 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam tmsri...@google.com wrote:
On Sat, May 26, 2012 at 4:56 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam tmsri...@google.com
wrote:
On
On Sat, May 26, 2012 at 7:23 PM, Sriraman Tallam tmsri...@google.com wrote:
Ｔhat is because libgcc_s.so is preferred by g++. We can do one
of 3 things:
1. Abuse libgcc_eh.a by moving __cpu_model and __cpu_indicator_init
from libgcc.a to libgcc_eh.a.
2. Rename libgcc_eh.a to libgcc_static.a
Hi,
[for certain test cases :-) ]
the temp slot cleanups I just sent where actually motivated by PR38474.
It exposes many slownesses in the compiler, but at -O0 the only remaining
one is the expand phase. expanding variables is the one thing (on my
machine here, with -O0 -g f951): 30
Hi,
On Fri, 25 May 2012, NightStrike wrote:
This point of yours should be stressed. Using writing standards of
one language to develop in another language is a fundamentally bad
idea. C and C++ kind of look the same, but they are not:
http://www.research.att.com/~bs/bs_faq.html#C-slash
94 matches
Mail list logo
