Should -Wpedantic warn on use of __auto_type ?
For example, should it warn in the following case ?
int main()
{
__auto_type x = 3;
return 0;
}
I feel so, since __auto_type is non-standard. If it should warn, is
the following fix correct ? I ran the above code snippet (with the fix
Hi,
Here is the proposal to update x86-64 PLT for MPX. The linker change
is implemented on hjl/mpx/pltext8 branch. Any comments/feedbacks?
Thanks.
--
H.J.
---
Intel MPX:
http://software.intel.com/en-us/file/319433-017pdf
introduces 4 bound registers, which will be used for parameter
On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REGISTER_OPERATIONS should have avoided the creation of such
paradoxical subreg.
No, that's precisely the contrary, WORD_REGISTER_OPERATIONS tends to create
paradoxical subregs.
I might
On Jan 18, 2014, at 12:04 PM, Paulo J. Matos pa...@matos-sorge.com wrote:
On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REISTER_OPERATIONS should have avoided the creation of such
paradoxical subreg.
No, that's precisely the
Hello,
Do we care if trunk doesn't compile successfully with
--enable-werror-always?
Do we want to fix things like:
../../../../gcc-trunk/fixincludes/server.c: In function ‘server_setup’:
../../../../gcc-trunk/fixincludes/server.c:195:10: error: ignoring
return value of ‘getcwd’, declared
On 18/01/14 20:11, pins...@gmail.com wrote:
On Jan 18, 2014, at 12:04 PM, Paulo J. Matos pa...@matos-sorge.com wrote:
On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REISTER_OPERATIONS should have avoided the creation of such
On Sat, 18 Jan 2014, Prathamesh Kulkarni wrote:
Should -Wpedantic warn on use of __auto_type ?
There is no general consistent rule followed for such reserved namespace
keywords. Your patch seems plausible (given testcase and %% quotes
around the keyword in the diagnostic text).
--
Joseph
On Sat, 18 Jan 2014, Paulo J. Matos wrote:
Hello,
Do we care if trunk doesn't compile successfully with --enable-werror-always?
The purpose of this option is to enable building of cross compilers to
fail on warnings in the same circumstances on which a native build would
fail (with the
Snapshot gcc-4.7-20140118 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140118/
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=59871
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
In fact current clang accepts the code as a GNU extension and we don't ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||emsr at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763
--- Comment #24 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #23)
(In reply to Jakub Jelinek from comment #22)
Created attachment 31868 [details]
gcc49-pr57763.patch
Uros, can you please
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Summary|No unused value warning for |[4.7/4.8/4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com ---
I went through the formal motions passed in Bristol and Chicago and didn't see
it, thus shouldn't be in C++14. C++17 maybe, nothing is decided yet.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
I'd say easiest would be at the spot where we warn currently about the
left-hand ... check if the left hand operand is a COMPOUND_EXPR, in that case
find the rightmost operand of all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
And similarly in emit_side_effect_warnings, if there are TREE_SIDE_EFFECTS, but
the expr is COMPOUND_EXPR, find the rightmost operand of the nested
COMPOUND_EXPRs and if it doesn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Sat Jan 18 10:18:33 2014
New Revision: 206750
URL: http://gcc.gnu.org/viewcvs?rev=206750root=gccview=rev
Log:
PR target/58944
* config/i386/i386-c.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
Bug ID: 59872
Summary: Cannot move std::map with move-only mapped_type
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Any comment about the following patch for testing the fix of this PR?
--- ../_clean/gcc/testsuite/gfortran.dg/round_3.f082011-05-05
03:54:21.0 +0200
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59869
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Component|c++ |libstdc++
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #1 from David Krauss potswa at mac dot com ---
It looks like the allocator-aware update introduced a copying branch to the
move constructor, to handle the case of transferring an object from one
stateful allocator to another.
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Yes, the branch that copies needs to be a separate function.
http://cplusplus.github.io/LWG/lwg-active.html#2108 might answer your last
question
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59580
--- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Sat Jan 18 13:25:40 2014
New Revision: 206756
URL: http://gcc.gnu.org/viewcvs?rev=206756root=gccview=rev
Log:
Update x86 --with-arch/--with-cpu= configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59583
--- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Sat Jan 18 13:25:40 2014
New Revision: 206756
URL: http://gcc.gnu.org/viewcvs?rev=206756root=gccview=rev
Log:
Update x86 --with-arch/--with-cpu= configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #3 from David Krauss potswa at mac dot com ---
Thanks, I'm working on it now.
Is there some precedent for this kind of SFINAE in libstdc++? The hard part is
getting the style right. Metaprogramming looks weird in 80 columns.
As for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59583
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59580
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774
--- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The change of behavior occurred between r203500 (2013-10-13) and r203859
(2013-10-19). Since libgfortran/io/write_float.def has not change between
r199598 and r206296 (Update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #4 from David Krauss potswa at mac dot com ---
Created attachment 31884
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31884action=edit
SFINAE based fix
This seems stylistically OK, but I did copy-paste the implementation of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
David Krauss potswa at mac dot com changed:
What|Removed |Added
Attachment #31884|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #6 from Akim Demaille akim.demaille at gmail dot com ---
FWIW, because of this issue, I no longer use g++ for my project, which saddens
me. If there were a means to put money on some bugs, I'd be happy to drop say
$50. I do not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58087
Sandro Mani manisandro at gmail dot com changed:
What|Removed |Added
Component|translation |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||jb at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59869
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656
--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
*** Bug 59869 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836
--- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
Dominiq,
Well, obviously we have a lot of history on this code and many changes to get
where we are now. Very much appreciate your analysis. A fresh look is always
helpful. If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55099
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I'll do the packaging over the week-end.
BTW this PR is a duplicate of what is left in pr48787 (part of it was already
analyzed in pr48787 comment 24).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||thenlich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867
--- Comment #7 from Username i-hate-registration at mailinator dot com ---
I've heard that it was previously expected to be in C++14, though it was
somehow forgotten, because the fix is quite small and one could currently do it
with a little bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #16 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to H.J. Lu from comment #15)
Either patch fixes the problem.
I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is
true.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #17 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Uroš Bizjak from comment #16)
(In reply to H.J. Lu from comment #15)
Either patch fixes the problem.
I prefer first patch. It splits all LEAs, where
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
--- Comment #13 from Mikael Morin mikael at gcc dot gnu.org ---
Author: mikael
Date: Sat Jan 18 20:05:25 2014
New Revision: 206759
URL: http://gcc.gnu.org/viewcvs?rev=206759root=gccview=rev
Log:
fortran/
PR fortran/58007
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733
--- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
With gold I get:
markus@x4 lto % cat 20090302_0.C
/* { dg-lto-do link } */
/* { dg-require-effective-target fpic } */
/* { dg-lto-options {{-fPIC -flto -flto-partition=1to1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59496
--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00816.html.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Cannot reproduce anymore.
I can reproduce it with gfortran 4.8.2, but not with trunk (r206759), nor with
4.7.4/4.8.3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
Bug ID: 59873
Summary: The value of char32_t U'\u' and char16_t u'\u000'
is 1, instead of 0.
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
Wesley J. Landaker wjl at icecavern dot net changed:
What|Removed |Added
Version|4.8.3 |4.9.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
--- Comment #2 from Wesley J. Landaker wjl at icecavern dot net ---
Created attachment 31886
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31886action=edit
The test.c++ program shown in the bug
For convenience, here is the test.c++ program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
--- Comment #3 from Wesley J. Landaker wjl at icecavern dot net ---
Created attachment 31887
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31887action=edit
A truncated version of char32_literal_test.c++
I also made another program that tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org ---
Seems to be on purpose, see the comment before _cpp_valid_ucn in
libcpp/charset.c, and the last instruction in that function.
[lex.charset] is a bit hard to read for me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
--- Comment #4 from Chengnian Sun chengniansun at gmail dot com ---
Thanks for your clarification, Harald, Jakub and Andrew.
I realize that the options -Wall -Wextra do not enable all the warnings. Is
there a flag in GCC which enables all the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Chengnian Sun from comment #4)
I realize that the options -Wall -Wextra do not enable all the warnings.
Is there a flag in GCC which enables all the available warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
--- Comment #5 from Wesley J. Landaker wjl at icecavern dot net ---
(In reply to Marc Glisse from comment #4)
Seems to be on purpose, see the comment before _cpp_valid_ucn in
libcpp/charset.c, and the last instruction in that function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129
--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr ---
On darwin10 I get the ICE with r202590 (2013-09-14), but not with r204463
(2013-11-06).
On darwin12/13 I don't get the ICE even for r201916.
May be fixed by revision 202823
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
--- Comment #6 from Andreas Schwab sch...@linux-m68k.org ---
\u is only malformed outside of string and char literals, eg. in
identifiers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
Wesley J. Landaker wjl at icecavern dot net changed:
What|Removed |Added
See Also|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
On darwin12/13 I don't get the ICE even for r201916.
I don't know what I did. After rechecking I found that r202804 gives the ICE
and r202825 does not.
The error is now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58928
--- Comment #5 from Michael Barker mikeb01 at gmail dot com ---
(In reply to Jakub Jelinek from comment #4)
Intel(R) Xeon(R) CPU E5620 @2.40GHz
is not IvyBridge, plus even IvyBridge doesn't support lzcnt insn, only
Haswell or some recent AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
Bug ID: 59874
Summary: Missing builtin (__builtin_clzs) when compiling with
g++
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875
Bug ID: 59875
Summary: Weak symbols in glibc prevent optimizations
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867
--- Comment #8 from Ed Smith-Rowland 3dw4rd at verizon dot net ---
I put this in a while back because it looked like it was going into C++14. I
jumped to gun. Unfortunately, I am not on a place where I can look at this
until Tuesday.
It should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
--- Comment #6 from Chengnian Sun chengniansun at gmail dot com ---
(In reply to Harald van Dijk from comment #2)
The type of a string literal in C is char[N], unlike in C++ where it is
const char[N]. clang's -Weverything option enables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Chengnian Sun from comment #6)
(In reply to Harald van Dijk from comment #2)
The type of a string literal in C is char[N], unlike in C++ where it is
const char[N].
On Fri, Jan 17, 2014 at 8:58 PM, Jakub Jelinek ja...@redhat.com wrote:
It makes no sense to warn about unused macros that weren't defined
by the user, but the compiler instead injected them, the user
has no control on them.
For macros predefined at the beginning of the CU we don't get
Jeff Law l...@redhat.com writes:
gcc/
* jump.c (delete_related_insns): Keep (use (insn))s.
* reorg.c (redundant_insn): Check for barriers too.
OK. Any chance you've got a testcase you can add to the suite? ISTM
it's potentially valuable given the plan to remove barriers and the
On Fri, Jan 17, 2014 at 09:31:00AM +0100, Jakub Jelinek wrote:
2014-01-17 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/57763
* bb-reorder.c (fix_crossing_unconditional_branches): Set JUMP_LABEL
on the new indirect jump_insn.
Eric requested LABEL_NUSES increment and
On Mon, Dec 23, 2013 at 3:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
Please get someone to review config.gcc changes. They are OK as far as
x86 rename is concerned, but I can't review functional changes.
Hi Paolo,
Can you review this config.gcc change?
@@ -588,6 +588,22 @@ esac
#
Review ping for this patch. IMO it almost counts as obviously correct
but just in case...
Kito Cheng k...@0xlab.org writes:
expand_movstr is work fine when we don't define movstr pattern or
always expand it successfully, however it's will crash when if movstr
expand fail since expand_insn
On Sat, Jan 18, 2014 at 10:37:18AM +, Richard Sandiford wrote:
Review ping for this patch. IMO it almost counts as obviously correct
but just in case...
Kito Cheng k...@0xlab.org writes:
expand_movstr is work fine when we don't define movstr pattern or
always expand it successfully,
Hello!
No functional changes, just some trivial code reordering while looking
in these areas.
2014-01-18 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (ix86_adjust_cost): Reorder PROCESSOR_K8
and PROCESSOR_ATHLON to simplify code. Move memory calculation.
2014-01-18 Uros Bizjak
On Sat, Jan 18, 2014 at 2:24 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Dec 23, 2013 at 3:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
Please get someone to review config.gcc changes. They are OK as far as
x86 rename is concerned, but I can't review functional changes.
Hi Paolo,
Can you
For LEA operation with SImode_address_operand, which zero-extends SImode
to DImode, ix86_split_lea_for_addr turns
(set (reg:DI) ...)
into
(set (reg:SI) ...)
We need to do
(set (reg:DI) (zero_extend:DI (reg:SI)))
at the end. If the LEA operation is
(set (reg:DI) (zero_extend:DI (reg:SI)))
Hello,
Le 11/01/2014 22:48, Janus Weil a écrit :
Good, thanks for checking. As written before, the patch is ok for
trunk from my side.
I finally committed it as revision 206759 (with the second testcase and
a bit more comments).
In fact your test case fails with all versions I tried (4.4,
On Thu, 2 Jan 2014, Jason Merrill wrote:
On 11/30/2013 05:41 AM, Marc Glisse wrote:
for some reason one of the attributes can see a FUNCTION_DECL where others
see an IDENTIFIER_NODE, I didn't try to understand why and just added that
check to the code.
Please do check.
In the C front-end
Hi,
while comparing LTO and non-LTO builds I noticed that with LTO we produce a lot
more vtables in datal.rel.ro rather than data.rel.ro.local
This is because of partitioning promoting more symbols global. For RTL we make
section decisions based on SYMBOL_REF_LOCAL_FLAG that is set based on
Hi Aldy,
I have answered your questions below. But, I am attaching the patch
with the response to Jason Merrill's email. I am not attaching them here to
remove unnecessary duplication. I hope that's OK with you. If you would like it
otherwise please let me know and I can send them to
Regex like a** will throw an unexpected exception. Now fixed (but
currently no optimizations on it).
Booted and tested with -m64 and -m32 respectively.
Thank you!
--
Regards,
Tim Shen
commit ceffce7f974d3ed58ba217807ffd431147ce717f
Author: tim timshe...@gmail.com
Date: Sat Jan 18 23:35:09
92 matches
Mail list logo
